On Tue, Aug 6, 2013 at 10:05 PM, Eric Sandeen <sand...@redhat.com> wrote: > On 8/6/13 3:45 PM, Filipe David Manana wrote: >> On Tue, Aug 6, 2013 at 9:37 PM, Eric Sandeen <sand...@redhat.com> 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.
I like that idea too. Thanks for the suggestion. A quick experiment allowed for that approach in under 20 lines, will test it a bit more. > > 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 > -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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
