* which lower filesystems are actually supported? @ 2019-06-01 20:01 Marco Nelissen 2019-06-02 6:42 ` Amir Goldstein 0 siblings, 1 reply; 6+ messages in thread From: Marco Nelissen @ 2019-06-01 20:01 UTC (permalink / raw) To: linux-unionfs According to the documentation, "The lower filesystem can be any filesystem supported by Linux", however this appears to not actually be the case, since using a vfat filesystem results in the mount command printing "mount: wrong fs type, bad option, bad superblock on overlay, missing codepage or helper program, or other error", with dmesg saying "overlayfs: filesystem on '/boot' not supported". (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) Should vfat be supported, or is the documentation wrong? If the documentation is wrong, what other filesystems are (not) supported? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: which lower filesystems are actually supported? 2019-06-01 20:01 which lower filesystems are actually supported? Marco Nelissen @ 2019-06-02 6:42 ` Amir Goldstein 2019-06-02 18:00 ` Theodore Ts'o 0 siblings, 1 reply; 6+ messages in thread From: Amir Goldstein @ 2019-06-02 6:42 UTC (permalink / raw) To: Marco Nelissen Cc: overlayfs, Ext4, Theodore Tso, Gabriel Krisman Bertazi, Darrick J. Wong [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4" On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote: > > According to the documentation, "The lower filesystem can be any filesystem > supported by Linux", however this appears to not actually be the case, since > using a vfat filesystem results in the mount command printing "mount: > wrong fs type, bad option, bad superblock on overlay, missing codepage or > helper program, or other error", with dmesg saying "overlayfs: filesystem on > '/boot' not supported". > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) Specifically for vfat it is weird because of dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE) because it is case insensitive. > > Should vfat be supported, or is the documentation wrong? If the documentation Documentation is wrong. > is wrong, what other filesystems are (not) supported? There are some special cases like /proc/sys and auto mount points, but the most common reason for unsupported lower is case insensitive filesystems and filesystems that support unicode character folding. Those filesystems MAY be case insensitive/unicode, depending on mkfs/mount options: adfs affs cifs efivarfs fat hfs hfsplus hpfs isofs isofs jfs xfs(*) ext4(**) (*) xfs case insensitive-ness feature is hidden from dcache (dcache is disabled), so overlayfs mount won't fail, but it may have unexpected behaviors. (**) ext4 supports per directory case insensitive and unicode folding since v5.2-rc1, if the filesystem was configured that way with mkfs/tune2fs. In this case, regardless of whether the lower dir is case insensitive or not, overlayfs mount will fail. I am guessing when people start using case insensitive enabled ext4, this problem is going to surface, because the same ext4 (e.g. root fs) could be used for samba export (case insensitive) and docker storage (overlayfs). I can think of some solutions for the private case of same case insensitive fs used for upper and lower, but let's see that the problem is real before discussing a solution. Ted, Gabriel, I didn't see that xfstests-bld was updated with case folding configs for ext4, nor that xfstests has any new case folding tests (saw some posted), so I guess that is still in the works (?). Did you happen to try out overlayfs/docker over a case insensitive enabled fs? I wonder if you could spare a few extra GCE instances per pre-release tests to run an overlay over ext4 config? I was nagging Darrick about this for a while and now I think the overlay/xfs config is being tested regularly. Beyond the fact that there are vast number of users using docker with overlay over ext4, overlayfs tends to find rare filesystem bugs because of its special use patterns (e.g. acd1d71598f7 "xfs: preserve i_rdev when recycling..."). Thanks, Amir. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: which lower filesystems are actually supported? 2019-06-02 6:42 ` Amir Goldstein @ 2019-06-02 18:00 ` Theodore Ts'o 2019-06-02 20:00 ` Amir Goldstein 2019-06-02 23:18 ` Amir Goldstein 0 siblings, 2 replies; 6+ messages in thread From: Theodore Ts'o @ 2019-06-02 18:00 UTC (permalink / raw) To: Amir Goldstein Cc: Marco Nelissen, overlayfs, Ext4, Gabriel Krisman Bertazi, Darrick J. Wong On Sun, Jun 02, 2019 at 09:42:54AM +0300, Amir Goldstein wrote: > [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4" > > On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote: > > > > According to the documentation, "The lower filesystem can be any filesystem > > supported by Linux", however this appears to not actually be the case, since > > using a vfat filesystem results in the mount command printing "mount: > > wrong fs type, bad option, bad superblock on overlay, missing codepage or > > helper program, or other error", with dmesg saying "overlayfs: filesystem on > > '/boot' not supported". > > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) > > Specifically for vfat it is weird because of > dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE) > because it is case insensitive. Marco, did you actually *need* to use the case insensitive feature? It is not turned on by default by e2fsprogs, and the assumption was that it only be turned in cases where it was needed --- e.g., VM's running Steam games that need Microsoft file system semantics, including case insensitivity, Samba (and eventually NFSv4) file servers for the same reason, and Android (so people won't have to try to get the abomination known as sdcardfs upstream :-). > > I am guessing when people start using case insensitive enabled ext4, > this problem > is going to surface, because the same ext4 (e.g. root fs) could be > used for samba > export (case insensitive) and docker storage (overlayfs). So I didn't think this would be that common, since you can certainly run Sambda without this new file system feature --- Samba has lived without it for over a decade. However, if you are running a high performance file server, it matters --- but if you're running a high performance file server, you're certainly not going to be trying to do it on the same server as one running Docker. Now, if you're trying to use overlayfs for some kind of snapshot application, then we'll need to figure out how to make overlayfs and ext4 work together --- but I view this as much more over an overlay compatibility issue than an ext4 bug. We *might* be able to only set the dentry functions on directory entries belonging to directories which have the casefold flag set, instead of simply setting it on all ext4 dentry entries. But still won't change the fact that overlayfs is going to have case insensitivity support if we want the combination of overlayfs && casefold to be supported. > I didn't see that xfstests-bld was updated with case folding configs for ext4, > nor that xfstests has any new case folding tests (saw some posted), so I guess > that is still in the works (?). That's correct, it's still on the todo list. > Did you happen to try out overlayfs/docker over a case insensitive enabled fs? Nope. I didn't think that was going to be a common use case. Docker is typically used on servers, where as case insensitivity is important for clients and file servers --- at least on the general case. > I wonder if you could spare a few extra GCE instances per pre-release tests > to run an overlay over ext4 config? > I was nagging Darrick about this for a while and now I think the > overlay/xfs config > is being tested regularly. It wouldn't be that hard to test overlayfs with ext4 for my pre-release testing. But it would only be in the default ext4 configuration --- and that doesn't include the case fold feature. - Ted ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: which lower filesystems are actually supported? 2019-06-02 18:00 ` Theodore Ts'o @ 2019-06-02 20:00 ` Amir Goldstein 2019-06-02 23:18 ` Amir Goldstein 1 sibling, 0 replies; 6+ messages in thread From: Amir Goldstein @ 2019-06-02 20:00 UTC (permalink / raw) To: Theodore Ts'o Cc: Marco Nelissen, overlayfs, Ext4, Gabriel Krisman Bertazi, Darrick J. Wong On Sun, Jun 2, 2019 at 9:01 PM Theodore Ts'o <tytso@mit.edu> wrote: > > On Sun, Jun 02, 2019 at 09:42:54AM +0300, Amir Goldstein wrote: > > [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4" > > > > On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote: > > > > > > According to the documentation, "The lower filesystem can be any filesystem > > > supported by Linux", however this appears to not actually be the case, since > > > using a vfat filesystem results in the mount command printing "mount: > > > wrong fs type, bad option, bad superblock on overlay, missing codepage or > > > helper program, or other error", with dmesg saying "overlayfs: filesystem on > > > '/boot' not supported". > > > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) > > > > Specifically for vfat it is weird because of > > dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE) > > because it is case insensitive. > > Marco, did you actually *need* to use the case insensitive feature? Marco reported the error on vfat and asked which other fs will have similar issue. > It is not turned on by default by e2fsprogs, and the assumption was > that it only be turned in cases where it was needed --- e.g., VM's > running Steam games that need Microsoft file system semantics, > including case insensitivity, Samba (and eventually NFSv4) file > servers for the same reason, and Android (so people won't have to try > to get the abomination known as sdcardfs upstream :-). > > > > > I am guessing when people start using case insensitive enabled ext4, > > this problem > > is going to surface, because the same ext4 (e.g. root fs) could be > > used for samba > > export (case insensitive) and docker storage (overlayfs). > > So I didn't think this would be that common, since you can certainly > run Sambda without this new file system feature --- Samba has lived > without it for over a decade. The performance penalty for brute force in some worse cases is abysmal. Most users don't know enough to blame the case insensitive compatibility layer. > However, if you are running a high > performance file server, it matters --- but if you're running a high > performance file server, you're certainly not going to be trying to do > it on the same server as one running Docker. Ted, people are using docker for anything these days. The chances that people won't use docker on the same machine where ext4 case insensitive was enabled are slim. It doesn't have to be high perf. server. It's enough that someone reads an article about improving Samba with ext4 to set it up for its home server. > > Now, if you're trying to use overlayfs for some kind of snapshot > application, then we'll need to figure out how to make overlayfs and > ext4 work together --- but I view this as much more over an overlay > compatibility issue than an ext4 bug. > Sure, but the complaints will start with "I enabled ext4 case insensitive and docker stopped working..." the sooner we are ready for this the better. > We *might* be able to only set the dentry functions on directory > entries belonging to directories which have the casefold flag set, > instead of simply setting it on all ext4 dentry entries. But still > won't change the fact that overlayfs is going to have case > insensitivity support if we want the combination of overlayfs && > casefold to be supported. > > > I didn't see that xfstests-bld was updated with case folding configs for ext4, > > nor that xfstests has any new case folding tests (saw some posted), so I guess > > that is still in the works (?). > > That's correct, it's still on the todo list. > > > Did you happen to try out overlayfs/docker over a case insensitive enabled fs? > > Nope. I didn't think that was going to be a common use case. Docker > is typically used on servers, where as case insensitivity is important > for clients and file servers --- at least on the general case. > > > I wonder if you could spare a few extra GCE instances per pre-release tests > > to run an overlay over ext4 config? > > I was nagging Darrick about this for a while and now I think the > > overlay/xfs config > > is being tested regularly. > > It wouldn't be that hard to test overlayfs with ext4 for my > pre-release testing. But it would only be in the default ext4 > configuration --- and that doesn't include the case fold feature. > Yep, that's what I had in mind. I know it wouldn't have caught this specific issue. Thanks, Amir. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: which lower filesystems are actually supported? 2019-06-02 18:00 ` Theodore Ts'o 2019-06-02 20:00 ` Amir Goldstein @ 2019-06-02 23:18 ` Amir Goldstein 2019-06-03 5:41 ` Gabriel Krisman Bertazi 1 sibling, 1 reply; 6+ messages in thread From: Amir Goldstein @ 2019-06-02 23:18 UTC (permalink / raw) To: Theodore Ts'o Cc: Marco Nelissen, overlayfs, Ext4, Gabriel Krisman Bertazi, Eric Biggers On Sun, Jun 2, 2019 at 9:01 PM Theodore Ts'o <tytso@mit.edu> wrote: > > On Sun, Jun 02, 2019 at 09:42:54AM +0300, Amir Goldstein wrote: > > [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4" > > > > On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote: > > > > > > According to the documentation, "The lower filesystem can be any filesystem > > > supported by Linux", however this appears to not actually be the case, since > > > using a vfat filesystem results in the mount command printing "mount: > > > wrong fs type, bad option, bad superblock on overlay, missing codepage or > > > helper program, or other error", with dmesg saying "overlayfs: filesystem on > > > '/boot' not supported". > > > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) > > > > Specifically for vfat it is weird because of > > dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE) > > because it is case insensitive. > [...] > > > > I am guessing when people start using case insensitive enabled ext4, > > this problem > > is going to surface, because the same ext4 (e.g. root fs) could be > > used for samba > > export (case insensitive) and docker storage (overlayfs). > [...] > > We *might* be able to only set the dentry functions on directory > entries belonging to directories which have the casefold flag set, > instead of simply setting it on all ext4 dentry entries. But still > won't change the fact that overlayfs is going to have case > insensitivity support if we want the combination of overlayfs && > casefold to be supported. > My intention was not that overlayfs should support casefold, just that an isolated casefold subdir in an ext4 fs shouldn't make the entire fs not usable with overlayfs. Incidentally, we already ran into a similar issue with ext4 encryption. Issue was reported by OpenWRT developers and fixed by: d456a33f041a fscrypt: only set dentry_operations on ciphertext dentries I recon casefold is taking a similar direction to the fs/crypto library, so solution should be similar as well. BTW, is casefold feature mutually exclusive with encryption feature? Because if it isn't, d_set_d_op() in __fscrypt_prepare_lookup() is going to WARN_ON dentry already has ext4_dentry_ops. Thanks, Amir. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: which lower filesystems are actually supported? 2019-06-02 23:18 ` Amir Goldstein @ 2019-06-03 5:41 ` Gabriel Krisman Bertazi 0 siblings, 0 replies; 6+ messages in thread From: Gabriel Krisman Bertazi @ 2019-06-03 5:41 UTC (permalink / raw) To: Amir Goldstein Cc: Theodore Ts'o, Marco Nelissen, overlayfs, Ext4, Eric Biggers Amir Goldstein <amir73il@gmail.com> writes: > On Sun, Jun 2, 2019 at 9:01 PM Theodore Ts'o <tytso@mit.edu> wrote: >> >> On Sun, Jun 02, 2019 at 09:42:54AM +0300, Amir Goldstein wrote: >> > [+cc ext4] Heads up on bug reports "Overlayfs fails to mount with ext4" >> > >> > On Sat, Jun 1, 2019 at 11:02 PM Marco Nelissen <marco.nelissen@gmail.com> wrote: >> > > >> > > According to the documentation, "The lower filesystem can be any filesystem >> > > supported by Linux", however this appears to not actually be the case, since >> > > using a vfat filesystem results in the mount command printing "mount: >> > > wrong fs type, bad option, bad superblock on overlay, missing codepage or >> > > helper program, or other error", with dmesg saying "overlayfs: filesystem on >> > > '/boot' not supported". >> > > (that's from ovl_mount_dir_noesc(), when ovl_dentry_weird() returns nonzero) >> > >> > Specifically for vfat it is weird because of >> > dentry->d_flags & (DCACHE_OP_HASH | DCACHE_OP_COMPARE) >> > because it is case insensitive. >> > [...] >> > >> > I am guessing when people start using case insensitive enabled ext4, >> > this problem >> > is going to surface, because the same ext4 (e.g. root fs) could be >> > used for samba >> > export (case insensitive) and docker storage (overlayfs). >> > [...] >> >> We *might* be able to only set the dentry functions on directory >> entries belonging to directories which have the casefold flag set, >> instead of simply setting it on all ext4 dentry entries. But still >> won't change the fact that overlayfs is going to have case >> insensitivity support if we want the combination of overlayfs && >> casefold to be supported. >> > > My intention was not that overlayfs should support casefold, just that > an isolated casefold subdir in an ext4 fs shouldn't make the entire fs > not usable with overlayfs. That is a reasonable request. I discussed a bit with Ted about how to not set dentry functions filesystem wide, because that gets in the way of fscrypt. I don't have a definite answer on how to do it, but it is something that I will try to fix to enable fscrypt+casefold support. > Incidentally, we already ran into a similar issue with ext4 encryption. > Issue was reported by OpenWRT developers and fixed by: > d456a33f041a fscrypt: only set dentry_operations on ciphertext dentries > > I recon casefold is taking a similar direction to the fs/crypto library, so > solution should be similar as well. > > BTW, is casefold feature mutually exclusive with encryption feature? > Because if it isn't, d_set_d_op() in __fscrypt_prepare_lookup() is > going to WARN_ON dentry already has ext4_dentry_ops. Not yet, and that is part of the reason. Right now, these two features cannot be enable simultaneously, but it is on my todo list to support that case. > Thanks, > Amir. -- Gabriel Krisman Bertazi ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-06-03 5:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-01 20:01 which lower filesystems are actually supported? Marco Nelissen 2019-06-02 6:42 ` Amir Goldstein 2019-06-02 18:00 ` Theodore Ts'o 2019-06-02 20:00 ` Amir Goldstein 2019-06-02 23:18 ` Amir Goldstein 2019-06-03 5:41 ` Gabriel Krisman Bertazi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.