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. Regards, Andrey On Tue, Nov 30, 2010 at 12:08 AM, Mike Fedyk <mfedyk@xxxxxxxxxxxxx> wrote: > On Mon, Nov 29, 2010 at 12:41 PM, David Arendt <admin@xxxxxxxxx> wrote: >> On 11/29/10 21:02, Mike Fedyk wrote: >>> >>> On Mon, Nov 29, 2010 at 12:02 AM, Li Zefan<lizf@xxxxxxxxxxxxxx> Âwrote: >>>> >>>> (Cc: Sage Weil<sage@xxxxxxxxxxxx> Âfor changes in async snapshots) >>>> >>>> This patchset adds readonly-snapshots support. You can create a >>>> readonly snapshot, and you can also set a snapshot readonly/writable >>>> on the fly. >>>> >>>> A few readonly checks are added in setattr, permission, remove_xattr >>>> and set_xattr callbacks, as well as in some ioctls. >>>> >>> Great work! >>> >>> I have a suggestion on defaults when snapshots are created. ÂI think >>> they should default to being read-only and if they are meant to be >>> read-write a flag can be set at creation time (and changable at a >>> later time as well of course). >>> >>> This way user/admin preconceptions of a snapshot being read-only can >>> be enforced by default, and the exception when you want a read-write >>> snapshot can be available with a switch at the cli level (and probably >>> a flag at the ioctl level). >>> >>> It gives one more natural distinction between a snapshot and a >>> subvolume at the user conceptual level. >>> >>> What do you think? >>> >> I completely agree with you. I think lots of people use snapshots for backup >> purposes and these ones shouldn't be writable. >> > .... by default. > -- > 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
