On 8/6/13 3:45 PM, Filipe David Manana wrote: > On Tue, Aug 6, 2013 at 9:37 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >> On 8/6/13 1:27 PM, Filipe David Borba Manana wrote: >>> This change allows for most mount options to be persisted in >>> the filesystem, and be applied when the filesystem is mounted. >>> If the same options are specified at mount time, the persisted >>> values for those options are ignored. >>> >>> The only options not supported are: subvol, subvolid, subvolrootid, >>> device and thread_pool. This limitation is due to how this feature >>> is implemented: basically there's an optional value (of type >>> struct btrfs_dir_item) in the tree of tree roots used to store the >>> list of options in the same format as they are passed to btrfs_mount(). >>> This means any mount option that takes effect before the tree of tree >>> roots is setup is not supported. >>> >>> To set these options, the user space tool btrfstune was modified >>> to persist the list of options into an unmounted filesystem's >>> tree of tree roots. >> >> So, it does this thing, ok - but why? >> What is seen as the administrative advantage of this new mechanism? >> >> Just to play devil's advocate, and to add a bit of history: >> >> On any production system, the filesystems will be mounted via fstab, >> which has the advantages of being widely known, well understood, and >> 100% expected - as well as being transparent, unsurprising, and seamless. >> >> For history: ext4 did this too. And now it's in a situation where it's >> got mount options coming at it from both the superblock and from >> the commandline (or fstab), and sometimes they conflict; it also tries >> to report mount options in /proc/mounts, but has grown hairy code >> to decide which ones to print and which ones to not print (if it's >> a "default" option, don't print it in /proc/mounts, but what's default, >> code-default or fs-default?) And it's really kind of an ugly mess. >> >> Further, mounting 2 filesystems w/ no options in fstab or on the >> commandline, and getting different behavior due to hidden (sorry, >> persistent) options in the fs itself is surprising, and surprise >> is rarely good. >> >> So this patch adds 100+ lines of new code, to implement this idea, but: >> what is the advantage? Unless there is a compelling administrative >> use case, I'd vote against it. Lines of code that don't exist don't >> have bugs. ;) > > There was a recent good example (imho at least) mentioned by Xavier > Gnata some time ago: > > http://comments.gmane.org/gmane.comp.file-systems.btrfs/26011 > > cheers Hm, I see. I forgot about hotplugging in my "most systems mount via fstab" assertion. :) I was thinking (and Josef just suggested too) that making a dir flag, saying "everything under this dir gets compressed" might make more sense for that scenario than adding a whole slew of on-disk-persistent-mount-option code. Because really, the motivation sounds like it's primarily for significant on-disk format changes controlled by mount options. I understand that motivation more than being able to persist something like "noatime." -Eric -- 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
