Yeah. I was merely curious about the architecture limits that drove the design this way, to begin with. Mostly because it seems "odd". It seems like the most obvious and most natural thing from the user's perspective to do would just be able to reflink directories. Like every decent source control system that exists, for instance. So, I figured there must be some very good reason it wasn't done like that. I'm still not completely sure what that very good reason is. Obviously whatever structure that currently exists for subvolumes would need to continue existing, to begin a unique inode scope. But, since apparently the VFS can be instructed to plop a new dev_id anywhere in the hierarchy, I I still don't see why explicit subvolumes are required. Seems more natural to be able to put a quota on a directory. To be able to set raid policy on a directory. Compression on a directory. COW semantics on a directory. Etc. Ahh well, some of you gave really nice detailed answers, and I appreciate that. Thanks. On Tue, Jul 23, 2013 at 4:52 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Jul 23, 2013, at 1:43 PM, Jerome Haltom <wasabi@xxxxxxxxx> wrote: > >> Why not just create the new dev_id on the destination snapshot of any >> directory? > > Right now, snapshots of subvolumes do not contain the contents of contained subvolumes. Hmmm, that sounds horrid. > > Subvolume A > File 1 > File 2 > Subvolume B > File 3 > File 4 > > If I snapshot subvolume A, the resulting snapshot does not contain File 3 and File 4. Subvolume B is a regular folder in the snapshot of Subvolume A. > > So if every directory were a subvolume by default, this limitation would need to be resolved or snapshotting would become useless. I'm sure there's a more coherent explanation why this isn't desired. > >> That way the snapshot can share inodes with is source. > > > Snapshots already share inode numbers. > > > Chris Murphy-- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
