Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom
On 10/28/2014 11:54 PM, Al Viro wrote: > On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: > >> >> We probably ought to split the normal (case-sensitive, no joliet shite) case >> out and leave it with NULL ->s_d_op, but that'll need to be done carefully, >> or isofs_cmp() will blow up on us. > > See if vfs.git#for-linus works for you. > Yes, works for me! Could mount the overlayfs, remove a file, add a file and modify a file. Not the definive stress-test I guess, but it's a start... Took only the following two commits: f643ff550afbc82a2bc7026f4a6d64427e4fbc9 5b71ecfa78271d5c576f17156ed8a53981c1ecb Kind regards Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom
On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: > Documentation is wildly over-optimistic. You are trying to use something > with non-trivial ->d_hash and ->d_compare as lower layer. > > What should happen if you ask to mount an image with joliet extensions and > ask to create foo.txt when foo.txt is there? From the isofs POV those > are the same; for overlayfs they are not (it's using default ->d_hash > and ->d_compare). > > We probably ought to split the normal (case-sensitive, no joliet shite) case > out and leave it with NULL ->s_d_op, but that'll need to be done carefully, > or isofs_cmp() will blow up on us. See if vfs.git#for-linus works for you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: "filesystem of lowerdir is not supported" on cdrom
On Tue, Oct 28, 2014 at 07:10:36PM +0100, Tim Tassonis wrote: > Hi > > Just installed 3.18-rc2 and tried to test the overlayfs stuff: > > $ mkdir /ovtmp > $ mount -t tmpfs tmpfs /ovtmp/ > $ mkdir /ovtmp/work > $ mkdir /ovtmp/upper > $ mkdir /cdrw > $ mount /dev/sr0 /mnt > $ mount |egrep "ovtmp|sr0" > > /dev/sr0 on /mnt type iso9660 (ro,relatime) > tmpfs on /ovtmp type tmpfs (rw,relatime) > > $ mount -t overlayfs overlayfs \ > -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw > [ 3266.793218] overlayfs: filesystem of lowerdir is not supported > > However, the doc in Documentation/filesystems/overlayfs.txt states: > > "The lower filesystem can be any filesystem supported by Linux and does > not need to be writable. The lower filesystem can even be another > overlayfs. The upper filesystem will normally be writable and if it > is it must support the creation of trusted.* extended attributes, and > must provide valid d_type in readdir responses, so NFS is not suitable." > > So: Is the documentation wrong, the error message in dmesg wrong, or > have missed something completely? Documentation is wildly over-optimistic. You are trying to use something with non-trivial ->d_hash and ->d_compare as lower layer. What should happen if you ask to mount an image with joliet extensions and ask to create foo.txt when foo.txt is there? From the isofs POV those are the same; for overlayfs they are not (it's using default ->d_hash and ->d_compare). We probably ought to split the normal (case-sensitive, no joliet shite) case out and leave it with NULL ->s_d_op, but that'll need to be done carefully, or isofs_cmp() will blow up on us. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
overlayfs: "filesystem of lowerdir is not supported" on cdrom
Hi Just installed 3.18-rc2 and tried to test the overlayfs stuff: $ mkdir /ovtmp $ mount -t tmpfs tmpfs /ovtmp/ $ mkdir /ovtmp/work $ mkdir /ovtmp/upper $ mkdir /cdrw $ mount /dev/sr0 /mnt $ mount |egrep "ovtmp|sr0" /dev/sr0 on /mnt type iso9660 (ro,relatime) tmpfs on /ovtmp type tmpfs (rw,relatime) $ mount -t overlayfs overlayfs \ -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. $ dmesg |tail [ 3266.793218] overlayfs: filesystem of lowerdir is not supported However, the doc in Documentation/filesystems/overlayfs.txt states: "The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable." So: Is the documentation wrong, the error message in dmesg wrong, or have missed something completely? Kind regards Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
overlayfs: filesystem of lowerdir is not supported on cdrom
Hi Just installed 3.18-rc2 and tried to test the overlayfs stuff: $ mkdir /ovtmp $ mount -t tmpfs tmpfs /ovtmp/ $ mkdir /ovtmp/work $ mkdir /ovtmp/upper $ mkdir /cdrw $ mount /dev/sr0 /mnt $ mount |egrep ovtmp|sr0 /dev/sr0 on /mnt type iso9660 (ro,relatime) tmpfs on /ovtmp type tmpfs (rw,relatime) $ mount -t overlayfs overlayfs \ -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw mount: wrong fs type, bad option, bad superblock on overlayfs, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. $ dmesg |tail [ 3266.793218] overlayfs: filesystem of lowerdir is not supported However, the doc in Documentation/filesystems/overlayfs.txt states: The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable. So: Is the documentation wrong, the error message in dmesg wrong, or have missed something completely? Kind regards Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: filesystem of lowerdir is not supported on cdrom
On Tue, Oct 28, 2014 at 07:10:36PM +0100, Tim Tassonis wrote: Hi Just installed 3.18-rc2 and tried to test the overlayfs stuff: $ mkdir /ovtmp $ mount -t tmpfs tmpfs /ovtmp/ $ mkdir /ovtmp/work $ mkdir /ovtmp/upper $ mkdir /cdrw $ mount /dev/sr0 /mnt $ mount |egrep ovtmp|sr0 /dev/sr0 on /mnt type iso9660 (ro,relatime) tmpfs on /ovtmp type tmpfs (rw,relatime) $ mount -t overlayfs overlayfs \ -olowerdir=/mnt,upperdir=/ovtmp/upper,workdir=/ovtmp/work /cdrw [ 3266.793218] overlayfs: filesystem of lowerdir is not supported However, the doc in Documentation/filesystems/overlayfs.txt states: The lower filesystem can be any filesystem supported by Linux and does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable. So: Is the documentation wrong, the error message in dmesg wrong, or have missed something completely? Documentation is wildly over-optimistic. You are trying to use something with non-trivial -d_hash and -d_compare as lower layer. What should happen if you ask to mount an image with joliet extensions and ask to create foo.txt when foo.txt is there? From the isofs POV those are the same; for overlayfs they are not (it's using default -d_hash and -d_compare). We probably ought to split the normal (case-sensitive, no joliet shite) case out and leave it with NULL -s_d_op, but that'll need to be done carefully, or isofs_cmp() will blow up on us. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: filesystem of lowerdir is not supported on cdrom
On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: Documentation is wildly over-optimistic. You are trying to use something with non-trivial -d_hash and -d_compare as lower layer. What should happen if you ask to mount an image with joliet extensions and ask to create foo.txt when foo.txt is there? From the isofs POV those are the same; for overlayfs they are not (it's using default -d_hash and -d_compare). We probably ought to split the normal (case-sensitive, no joliet shite) case out and leave it with NULL -s_d_op, but that'll need to be done carefully, or isofs_cmp() will blow up on us. See if vfs.git#for-linus works for you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: overlayfs: filesystem of lowerdir is not supported on cdrom
On 10/28/2014 11:54 PM, Al Viro wrote: On Tue, Oct 28, 2014 at 09:13:13PM +, Al Viro wrote: We probably ought to split the normal (case-sensitive, no joliet shite) case out and leave it with NULL -s_d_op, but that'll need to be done carefully, or isofs_cmp() will blow up on us. See if vfs.git#for-linus works for you. Yes, works for me! Could mount the overlayfs, remove a file, add a file and modify a file. Not the definive stress-test I guess, but it's a start... Took only the following two commits: f643ff550afbc82a2bc7026f4a6d64427e4fbc9 5b71ecfa78271d5c576f17156ed8a53981c1ecb Kind regards Tim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
