On Mon, Jan 12, 2015 at 3:35 AM, <sf...@users.sourceforge.net> wrote: > > Daniel Smedegaard Buus: > >> First of all, having to go mainline vanilla is not a biggie, I will >> probably have to anyway, as I need to use SCST, and my last attempts >> of building that only worked with mainline kernels. > > Then I'd ask you to re-build aufs with CONFIG_AUFS_DEBUG=y and try these > commands. > # mkdir /tmp/a > # mount "loopback ext4 or tmpfs" /tmp/a > # echo 1 > /sys/module/aufs/parameters/debug > # mount -t aufs -o ro,verbose,xino=/tmp/a/xino, > br=/titanic/Downloads/Processed=ro:/titanic/Volumes/XD001=ro > none /Archive > # echo 0 > /sys/module/aufs/parameters/debug > And see the kernel logs. >
Righty-O, I'll do that now then :) (*EDIT*: Actually, considering the discoveries below, do you still need me to do this? AFAICT, the behavior is pretty clear now, and I don't think this is a bug as such, just a limitation, and perhaps all that's needed is a descriptive error message when a mount such as mine fails.) > >> Oh, and the ZFS I'm using is the ZFS on Linux one, that is the native >> implementation. > > For your information, you may want to read this mail and its thread. > http://www.mail-archive.com/aufs-users%40lists.sourceforge.net/msg04381.html > titled "unable to write via nfs to aufs of zfs branches" > Currently it may not be related to your problem though. > Might, though — at least it has the ingredients to match :D On my end, I've never tried to set up NFS support for AUFS, as the 3.11 Ubuntu kernel needed to be recompiled to do so, and I simply never got around to it. I never needed to write to AUFS either, as my /Archive mount is meant to be a read-only repository of mostly media files. Hmmm, correct that: I actually did set it up with write support initially, writing to something like /titanic/Archive/Incoming (on ZFS as well), which worked just fine. The date is interesting, though — back in September 2013. That means he was probably using the same versions of both AUFS and ZFS that I was using before I upgraded. > Here are what I am currently guessing. > - Your current (unpatched) aufs doesn't support writable zfs branch, but > supports readonly zfs branch. > - Yet I don't know whether your zfs supports aio_read/write functions or > not. > - I've confirmed that latest aufs supports writable btrfs branch, but > not readonly. It may be the reason why "mount -v -t aufs -o > br:/root/a:/root/b none /root/c" failed. > - Internally aufs uses XINO file (for details, please refer to aufs > manual), and it cannot be put on zfs and btrfs. So you need to add > "xino=path" option. The path should be other than zfs and btrfs. > Okay, I just tried mounting my AUFS /Archive using ro,xino=/<mounted tmpfs>/xino and no writable folders. Worked perfectly. This matches exactly what you say about the xino file not being compatible with btrfs and zfs. Couple of questions arise: *) If you don't specify "xino=<some file>", what happens? The manpage says that it ends up in the first writable branch. But what if that branch isn't writable, or if it is writable but fails as it does with zfs? Does AUFS then try to write it to /tmp/ in both cases? That would explain why everything worked for me before, as my root fs was ext4. When I has a writable AUFS working on my old installation, I could write files to it, and they ended up where expected — is it only the XINO file that requires specific filesystem? - Okay, I actually just thought, "Why not just test that?", and indeed — as long as I specify xino=<somewhere NOT on btrfs or zfs>, then I can also use a writable branch entirely on zfs, and anything written to /Archive ends up on zfs as well. So, it seems to be the case that the XINO stuff cannot reside on neither zfs nor btrfs. So if you're using btrfs or zfs, you CAN use folders there to aggregate with AUFS, you just HAVE to tell AUFS to put the xino file somewhere else. *) It seems that only writing to the AUFS mount will make the XINO file grow, is that correct? So, if I have a read-only mount, I can get away with using a very very small tmpfs mount for the XINO file? But, just for future reference, what if you use xino= on a writable branch. What makes it grow, and how can you calculate how much space to reserve for it? Since I'm using a tmpfs, it'd be nice not to spend too much mem needlessly :D > >> First of all, the -o verbose option doesn't seem to make any >> difference =E2=80=94 the logged messages are exactly the same as without. > > Hmm... It means I should add more messages in aufs. But this will be > another issue now. Anyway thanx for testing. > No — thank YOU for helping me! You're very kind :) > >> Second of all, I've discovered that all I need to do to mount my >> ZFS-backed AUFS volume is to add ONE source on the EXT4 partition and >> the mount succeeds. (By the way, it seems that I'm not allowed to >> create an AUFS mount with only read-only sources anymore? If I try, I >> always get syslog messages that, "first branch should be rw"?) > > Without "-o ro" mount option, at least one writable branch is necessary > for aufs. Otherwise the msg "first branch should be rw" is produced. It > is reasonable, isn't it? > Definitely — it just wasn't like that on my Saucy installation :) > But even if your all branches are specified "=ro" without "-o ro" > option, the mount itself should succeed (as long as the branches are > suppported by aufs). I know you got an error, so we need to investigate > more on that. > Oh :D > ---------------------------------------------------------------------- > >> I also noticed while trying out different sizes of dummy tmpfses to >> find the minimum size needed for aufs to mount successfully, that if >> the tmpfs rw target is too small, say 256k, the mount will fail (with >> the "wrong fs type, ..." message), but the target will be populated >> with ".wh..wh.aufs", ".wh..wh.orph/", and ".wh..wh.plnk/", and any >> attempt at unmounting it will fail with "target is busy", even though >> aufs never mounted... > > Aufs should reject being mounted when the writable branch is too small > enough to create these ".wh." entries. The behaviour you saw is OK. > But "target is busy" looks strange. I wonder you might be trying > unmounting the system root? No? > Actually, I was trying to figure out how small I could make the tmpfs and have aufs successfully mount /Archive. So I would do something like, "mount -t tmpfs -o size=200k ext4 /dummy", and then try to mount /Archive with /dummy as a writable branch. AUFS would fail with the usual error message, and after that, I could not umount /dummy, as it was busy, and inside /dummy were the .wh_* files and folders. Thanks again! :) Daniel ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. vanity: www.gigenet.com
