On Wed, Apr 19, 2017 at 6:33 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, Apr 19, 2017 at 5:27 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Wed, Apr 19, 2017 at 6:16 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >>> On Mon, Apr 17, 2017 at 1:59 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>>> When mounted with mount option redirect_dir=fh, >>>> every copy up of lower directory stores the lower >>>> dir file handle in overlay.fh xattr of upper dir. >>> >>> Is there a disadvantage to doing this unconditionally? (Same goes for patch 4) >>> >>> Is there a disadvantage to doing this even for the non-samefs case? >>> >> >> Not that I can think of. It's just that all the features that stable >> inode brings >> to the table only work for same_fs right now, but we can store overlay.fh >> anyway. >> >> When you get a chance please let me know your preference wrt >> configuration options. >> I don't see a reason to let the user turn off storing overlay.fh? >> Is there a reason to let user turn off lookup by fh? for files? >> (i.e. to preserve old weird behavior?) > > The less config options the better. > > We needed the redirect_dir=on/off thing because it's a backward > incompatible format change and the alternatives sucked more (i.e. > Linus didn't like them). > > I don't see why we'd need to allow turning off backward compatible > changes (of course, there's a minimal overhead, but lets assume that > nobody cares about that, and if it turns out to be a problem, we'll > fix it). > There is one slightly hackish reason for which I find redirect_dir=fh mount option useful. redirect_fh it automatically turned on|off depending on same_fs configuration. When I look at the mount options at /proc/mounts I can see redirect_dir=fh|on which gives me an indication if I can expect the stable inodes behavior. This sort of info can be useful for support calls, but I guess it belongs somewhere under sysfs or debugfs... Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
