On Nov 29, 2010, at 3:48 PM, Andrey Kuzmin <andrey.v.kuz...@gmail.com> wrote:
> I'm not sure why zfs came up, they don't own the term :). As to > zfs/overhead topic, I doubt there's any difference between clone and > writable shapshot (there should be none, of course, it's just two > different names for the same concept). > > Regards, > Andrey > > > > > On Tue, Nov 30, 2010 at 12:43 AM, Mike Fedyk <mfe...@mikefedyk.com> > wrote: >> On Mon, Nov 29, 2010 at 1:31 PM, Andrey Kuzmin >> <andrey.v.kuz...@gmail.com> wrote: >>> This may sound excessive as any new concept introduction that late >>> in >>> development, but readonly/writable snapshots could be further >>> differentiated by naming the latter clones. This way end-user would >>> naturally perceive snapsot as read-only PIT fs image, while clone >>> would naturally refer to (writable) head fork. >>> >> >> I'm not sure we want to take all of the terminology that zfs uses as >> it may also bring the percieved drawbacks as well. Isn't there some >> additional overhead for a zfs clone compared to a snapshot? I'm not >> very familiar with zfs so that's why I ask. >> > -- > To unsubscribe from this list: send the line "unsubscribe linux- > btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I don't like the idea of readonly by default, or further changes to terminology, for several reasons: ) readonly by default offers no real enhancement whatsoever other than breaking _anything_ that's written right now ) btrfs readonly is not even really readonly; as superuser could simply flip a flag to enable writes, readonly merely prevents accidental writes or misbehaving apps... ie. protecting you from yourself ) backups are the simple/obvious use case; I personally use btrfs heavily for LXC containers, in which case nearly every single snapshot is intended to be writable -- usually cloning a template into a new domain ) I also use an initramfs hook to provide system rollbacks, also writable; the hook also provides multiple versions of the "branch"... all writable ) adding new terms is not a good idea imo; I've already spewed out many sentences explaining the difference between subvolumes and snapshots, ie. that there is none... adding another term only adds to this problem; they each describe the same thing, but differentiate based on origin or current state, neither of which actually describe what it _is_-- a new named pointer to a tree, like a git branch -- a subvolume. I think a better solution/compromise would be to leave snapshots writeable by default, since that's more true to what's happening internally anyway, but maybe introduce a mount option controlling the default action for that mount point. C Anthony [mobile] -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
