I hope everything is fine Mr. Okajima and the Japanese community.
My prayers always with you.
2011/3/25 <[1][email protected]>
Send Aufs-users mailing list submissions to
[2][email protected]
To subscribe or unsubscribe via the World Wide Web, visit
[3]https://lists.sourceforge.net/lists/listinfo/aufs-users
or, via email, send a message with subject or body 'help' to
[4][email protected]
You can reach the person managing the list at
[5][email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Aufs-users digest..."
Today's Topics:
1. Re: Excluding files/dirs from when aufs is mounted on top of
read-only directory ([6][email protected])
2. Re: Bug report + solution ([7][email protected])
3. Re: kernel BUG at dynop.c:199 ([8][email protected])
4. Re: [PATCH 0/6 v7] overlay filesystem - request for inclusion
(Hans-Peter Jansen)
5. Cached memory on write is gone. (Anatoly)
6. Re: Cached memory on write is gone. ([9][email protected])
7. Using aufs as a COW system for LXC? (Milan Zamazal)
8. Re: Using aufs as a COW system for LXC?
([10][email protected])
---------- Forwarded message ----------
From: [11][email protected]
To: "Søren Rasmussen" <[12][email protected]>
Date: Mon, 21 Mar 2011 17:48:36 +0900
Subject: Re: Excluding files/dirs from when aufs is mounted on top of
read-only directory
Hello Soren,
S?ren Rasmussen:
> I have an aufs mount mounted on top of the ro directory like this:
> # mount -t aufs -o airs=./rwdir=rw:./rodir=ro none ./rodir
> I want to exclude a file "exfile" in ./rodir from aufs, so changes get
> written directly to the ro-branch, not ./rwdir.
> I have tried bind mounting in several different ways (both before and
> after the mount command above):
> 1):
> # touch ./rwdir/exfile
> # mount -B ./rodir/exfile ./rwdir/exfile
> 2):
> # mount -B ./rodir/exfile ./rodir/exfile
I guess it was just because the mount point is same to the RO branch
(./rodir).
You need to run "mount -B" _after_ mounting aufs, but you cannot refer
to the RO branch "rodir" directly anymore. It is covered by aufs
"rodir".
Try something like this (I didn't try by myself though).
# mount -t aufs -o airs=./rwdir=rw:./rodir=ro none ./rodir.tmp
# mount -B ./rodir/exfile ./rodir.tmp/exfile
# mount -M ./rodir.tmp ./rodir
J. R. Okajima
---------- Forwarded message ----------
From: [13][email protected]
To: Dean Takemori <[14][email protected]>
Date: Mon, 21 Mar 2011 17:55:57 +0900
Subject: Re: Bug report + solution
Hello Dean,
Dean Takemori:
> This is the patch I'm using in my personal build tree to revert
> the part of the grsecurity patch that conflicts with aufs.
If you have aufs2-standalone.git, you will find
"grsecurity-2.1.14-2.6.33.4.patch" in aufs2.1-33 branch.
This patch makes aufs to bypass "the grsec trick which makes developers
think twice" and enables aufs2 cowork with the grsec patch.
The line number in the patch may differ from another version of grsec,
but it is easy to address I think.
J. R. Okajima
---------- Forwarded message ----------
From: [15][email protected]
To: Jan Engelhardt <[16][email protected]>
Date: Mon, 21 Mar 2011 18:05:26 +0900
Subject: Re: kernel BUG at dynop.c:199
Jan Engelhardt:
> Mar 19 15:36:40 134.76.82.230 [ 202.960778] kernel BUG at
/usr/src/packages/BUILD/aufs-2.1~20110214/obj/desktop/fs/aufs/dynop.c:199!
This line verifies the size of struct address_space_operation.
If it is modified by another kernel patch, aufs crashes at this line to
prevent you from further corupption.
Did you apply another kernel patch? Or did you change the module build
option from the kernel's?
J. R. Okajima
---------- Forwarded message ----------
From: "Hans-Peter Jansen" <[17][email protected]>
To: Xianghua Xiao <[18][email protected]>
Date: Wed, 23 Mar 2011 00:13:41 +0100
Subject: Re: [PATCH 0/6 v7] overlay filesystem - request for inclusion
On Tuesday 22 March 2011, 19:49:44 Xianghua Xiao wrote:
> On Tue, Mar 22, 2011 at 1:22 PM, Felix Fietkau <[19][email protected]>
wrote:
> > On 2011-03-22 6:36 PM, Linus Torvalds wrote:
> >> On Tue, Mar 22, 2011 at 8:26 AM, Miklos Szeredi
<[20][email protected]>
wrote:
> >>> Here's an updated version of the overlay filesystem. I'd like to
> >>> propose it for inclusion into mainline.
> >>
> >> So on the whole it looked pretty small and simple. And most of the
> >> VFS level changes looked fine and I just reacted to the odd
> >> calling convention for open (I really think you should aim for
> >> ->open to have the basically same arguments as you made
> >> __dentry_open have: 'struct path', 'struct filp' and 'struct
> >> cred').
> >>
> >> But I'd want Al's ack on the series. And also hear who uses it and
> >> how it's been tested?
> >
> > We're using it in OpenWrt (an Embedded Linux distribution) for
> > devices with tiny amounts of flash for the entire system (e.g. 4
> > MB). We're using it to provide a writable on-flash root filesystem
> > with squashfs for the read-only part and jffs2 for the writable
> > overlay. This saves some precious flash space compared to using
> > only jffs2, and it makes it easy for users to reset their device to
> > defaults without having to reflash.
> > With a backport of v6 of this series + my fixes that went into v7
> > this is working quite well on 2.6.37 and 2.6.38 - I'm using it on a
> > few wireless access points at home.
> >
> > - Felix
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to
[21][email protected]
> > More majordomo info at [22]http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at [23]http://www.tux.org/lkml/
>
> how is this filesystem related to mini_fo and unionfs?
and aufs2: it's a minimalistic version of a layered filesystem, being
much less capable then its ancestors, but hopefully the right approach
to get the foot in the door.. Unfortunately, it's locking out NFS,
which is a big miss for diskless usage scenarios (where layered
filesystems are also used commonly since ages..).
Probably, it will grow up, Al gets the VFS sorted out from a FS layering
perspective, Valerie Aurora and friends get union mounts operating and
merged, and/or Linus finally merges Junjiro Okajima's aufs2, which is
often used in production environments today, where other layered
filesystem approaches are unusable or simply fail in practice.
Btw: Fortunately, Junjiro, being a Tokio habitant, wasn't injured from
the earth quake nor the tzunami, and let us all pray five minutes for
success and survival of those brave guys, that try to fix the cooling
in the Fukushima atomic plant.
Pete
---------- Forwarded message ----------
From: Anatoly <[24][email protected]>
To: [25][email protected]
Date: Thu, 24 Mar 2011 13:03:28 +0300
Subject: Cached memory on write is gone.
# uname -a
Linux butt1 2.6.32.32-0.1-default #1 SMP Mon Mar 14 12:33:30 MSK 2011
x86_64 x86_64 x86_64 GNU/Linux
# zcat /proc/config.gz | grep AUFS
CONFIG_AUFS_FS=y
# CONFIG_AUFS_BRANCH_MAX_127 is not set
# CONFIG_AUFS_BRANCH_MAX_511 is not set
CONFIG_AUFS_BRANCH_MAX_1023=y
# CONFIG_AUFS_BRANCH_MAX_32767 is not set
CONFIG_AUFS_SBILIST=y
# CONFIG_AUFS_HNOTIFY is not set
# CONFIG_AUFS_RDU is not set
# CONFIG_AUFS_SP_IATTR is not set
# CONFIG_AUFS_SHWH is not set
# CONFIG_AUFS_BR_RAMFS is not set
# CONFIG_AUFS_BR_FUSE is not set
CONFIG_AUFS_BR_HFSPLUS=y
CONFIG_AUFS_BDEV_LOOP=y
# CONFIG_AUFS_DEBUG is not set
# cat /proc/mounts
rootfs / rootfs rw 0 0
udev /dev tmpfs rw,relatime,mode=755 0 0
/dev/sda2 / xfs rw,relatime,attr2,noquota 0 0
/proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620 0 0
/dev/sda1 /boot ext3
rw,relatime,errors=continue,user_xattr,acl,data=writeback 0 0
/dev/sdb /mnt/g1/0 xfs rw,relatime,attr2,noquota 0 0
/dev/sdc /mnt/g2/0 xfs rw,relatime,attr2,noquota 0 0
/dev/md2 /mnt/backup_mirror_0001 xfs
rw,noatime,nodiratime,attr2,inode64,logbufs=8,logbsize=256k,noquota 0
0
/dev/md0 /mnt/backup_mirror_0002 xfs
rw,noatime,nodiratime,attr2,inode64,logbufs=8,logbsize=256k,noquota 0
0
/dev/md1 /mnt/backup_mirror_0003 xfs
rw,noatime,nodiratime,attr2,inode64,logbufs=8,logbsize=256k,noquota 0
0
/dev/md3 /mnt/backup_mirror_0004 xfs
rw,noatime,nodiratime,attr2,inode64,logbufs=8,logbsize=256k,noquota 0
0
/dev/md4 /mnt/backup_mirror_0005 xfs
rw,noatime,nodiratime,attr2,inode64,logbufs=8,logbsize=256k,noquota 0
0
/dev/sda7 /db xfs rw,relatime,attr2,noquota 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sdi /xino ext3 rw,relatime,errors=continue,data=writeback 0 0
none /mnt/backup_mirror_global aufs
rw,relatime,si=586e167e8b86b525,create=mfs,sum 0 0
# cat /sys/module/aufs/parameters/brs
1
Reproduce:
# free -m
total used free shared buffers cached
Mem: 3895 309 3585 0 0 141
-/+ buffers/cache: 167 3727
Swap: 0 0 0
# dd if=/dev/zero of=test2
^C9697128+0 records in
9697128+0 records out
4964929536 bytes (5.0 GB) copied, 54.2538 s, 91.5 MB/s
# free -m
total used free shared buffers cached
Mem: 3895 3861 33 0 0 3693
-/+ buffers/cache: 167 3727
Swap: 0 0 0
# cat /proc/meminfo | grep Cache
Cached: 3646976 kB
SwapCached: 0 kB
# rm -rf test2
# free -m
total used free shared buffers cached
Mem: 3895 238 3656 0 0 71
-/+ buffers/cache: 166 3728
Swap: 0 0 0
# cat /proc/meminfo | grep Cache
Cached: 49656 kB
SwapCached: 0 kB
butt2:/mnt/test_storage #
When I write to the mount point. All my memory is gone..
---------- Forwarded message ----------
From: [26][email protected]
To: Anatoly <[27][email protected]>
Date: Thu, 24 Mar 2011 21:48:20 +0900
Subject: Re: Cached memory on write is gone.
Hello Anatoly,
Anatoly:
> When I write to the mount point. All my memory is gone..
Unfortunately I could not get what you want to point out.
What does it mean "All my memory is gone"?
Generally the cache for files read from the disk can be discarded
anytime. It is totally up to your system (kernel memory management).
What is do you think a problem?
J. R. Okajima
---------- Forwarded message ----------
From: Milan Zamazal <[28][email protected]>
To: [29][email protected]
Date: Fri, 25 Mar 2011 08:44:20 +0100
Subject: Using aufs as a COW system for LXC?
I moved from Linux VServer to Linux containers and looked for an
equivalent of the VServer hashify facility. I tried to run aufs as a
copy-on-write file system over the tree of interlinked files, mounting
it with `br:/var/lib/vservers.branch:/var/lib/vservers.orig,noplink'
(using noplink in order to break the links on file changes). The system
is Debian 6.0 amd64 ext3.
I had to abandon aufs very soon because of the following problems:
1. Making a new hard link to some files failed with an error. This is a
serious problem that has broken all my `apt-get upgrade' attempts.
2. Aubrsync printed error messages about an inaccessible file
occasionally. This looked relatively harmless as the "inaccessible"
files were actually unchanged so nothing bad happened when they were
not copied back. But it makes me worrying about aubrsync/aufs
reliability.
3. When I change one of two hard-linked files, `ls -l' still shows
identical information for both of them, although the contents and
sizes of the files are different after the change. No big problem,
but it is confusing.
4. On one occasion any attempt to write to a (writable) file failed.
This is a serious problem.
None of these problems was present in the underlying
/var/lib/vservers.orig directory, I could successfully perform all the
operations on the same files in it. I know aufs in the stable Debian
kernel is not the newest one (according to the kernel changelog it is
2010-01-25 snapshot). My questions are:
- Is it possible that I did something wrong?
- If those are aufs bugs, are they fixed in current aufs or Linux?
- If aufs is really unusable for the purpose, do you know about any
reasonable way to emulate hashify on Linux containers?
---------- Forwarded message ----------
From: [30][email protected]
To: Milan Zamazal <[31][email protected]>
Date: Fri, 25 Mar 2011 21:58:57 +0900
Subject: Re: Using aufs as a COW system for LXC?
Hello Milan,
Milan Zamazal:
> 1. Making a new hard link to some files failed with an error. This is a
> serious problem that has broken all my `apt-get upgrade' attempts.
Although the details are not clear, hardlink in aufs is working for a
long time. Here is an example test output.
+ sudo mount -o remount,noplink /dev/shm/u
+ tail -n 3 /proc/mounts
/dev/ram1 /dev/shm/ro ext2 ro,relatime,errors=continue 0 0
/dev/ram0 /dev/shm/rw ext3
rw,relatime,errors=continue,barrier=0,data=writeback 0 0
none /dev/shm/u aufs rw,relatime,si=33d9ce2780c03f3f,noplink 0 0
+ cat /sys/fs/aufs/si_33d9ce2780c03f3f/br0
/sys/fs/aufs/si_33d9ce2780c03f3f/br1
/dev/shm/rw=rw
/dev/shm/ro=ro
(now /dev/shm/u = /dev/shm/rw + /dev/shm/ro)
+ ls -li ../ro/f_src ../ro/f_src_linked ../ro/f_src_linked2
17 -rw-r--r-- 1 jro jro 2 Mar 25 21:50 ../ro/f_src
15 -rw-r--r-- 2 jro jro 2 Mar 25 21:50 ../ro/f_src_linked
15 -rw-r--r-- 2 jro jro 2 Mar 25 21:50 ../ro/f_src_linked2
+ ls -li ../rw/f_src ../rw/f_src_linked*
ls: cannot access ../rw/f_src: No such file or directory
ls: cannot access ../rw/f_src_linked*: No such file or directory
+ :
+ ls -li ./f_src ./f_src_linked ./f_src_linked2
22 -rw-r--r-- 1 jro jro 2 Mar 25 21:50 ./f_src
21 -rw-r--r-- 2 jro jro 2 Mar 25 21:50 ./f_src_linked
21 -rw-r--r-- 2 jro jro 2 Mar 25 21:50 ./f_src_linked2
(the f_src* files exist on RO but RW, f_src_linked* are hardlinked)
+ ln ./f_src ./newfile
+ ln ./f_src_linked ./newfile_linked
(create two new hardlinks)
+ ls -li f_src f_src_linked f_src_linked2 newfile newfile_linked
22 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 f_src
21 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 f_src_linked
21 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 f_src_linked2
22 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 newfile
21 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 newfile_linked
(their inode numbers are expectedly correct, but ...)
+ sudo mount -o remount /dev/shm/u
+ ls -li f_src f_src_linked f_src_linked2 newfile newfile_linked
22 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 f_src
21 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 f_src_linked
55 -rw-r--r-- 2 jro jro 2 Mar 25 21:50 f_src_linked2
22 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 newfile
21 -rw-r--r-- 2 jro jro 1 Mar 25 21:50 newfile_linked
(after discarding the system cache, the inum of f_src_linked2 is
changed. It is simply due to 'noplink' which doesn't maintain the
hardlink between branches)
> 2. Aubrsync printed error messages about an inaccessible file
> occasionally. This looked relatively harmless as the "inaccessible"
> files were actually unchanged so nothing bad happened when they were
> not copied back. But it makes me worrying about aubrsync/aufs
> reliability.
>
> 3. When I change one of two hard-linked files, `ls -l' still shows
> identical information for both of them, although the contents and
> sizes of the files are different after the change. No big problem,
> but it is confusing.
>
> 4. On one occasion any attempt to write to a (writable) file failed.
> This is a serious problem.
>
> None of these problems was present in the underlying
> /var/lib/vservers.orig directory, I could successfully perform all the
> operations on the same files in it. I know aufs in the stable Debian
> kernel is not the newest one (according to the kernel changelog it is
> 2010-01-25 snapshot). My questions are:
I am afraid your aufs module is totally broken.
As you wrote, such old version is obsolete and not maintained now.
> - Is it possible that I did something wrong?
>
> - If those are aufs bugs, are they fixed in current aufs or Linux?
I'd strongly suggest you to try latest version.
J. R. Okajima
--------------------------------------------------------------------------
----
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! [32]http://p.sf.net/sfu/intel-dev2devmar
References
1. mailto:[email protected]
2. mailto:[email protected]
3. https://lists.sourceforge.net/lists/listinfo/aufs-users
4. mailto:[email protected]
5. mailto:[email protected]
6. mailto:[email protected]
7. mailto:[email protected]
8. mailto:[email protected]
9. mailto:[email protected]
10. mailto:[email protected]
11. mailto:[email protected]
12. mailto:[email protected]
13. mailto:[email protected]
14. mailto:[email protected]
15. mailto:[email protected]
16. mailto:[email protected]
17. mailto:[email protected]
18. mailto:[email protected]
19. mailto:[email protected]
20. mailto:[email protected]
21. mailto:[email protected]
22. http://vger.kernel.org/majordomo-info.html
23. http://www.tux.org/lkml/
24. mailto:[email protected]
25. mailto:[email protected]
26. mailto:[email protected]
27. mailto:[email protected]
28. mailto:[email protected]
29. mailto:[email protected]
30. mailto:[email protected]
31. mailto:[email protected]
32. http://p.sf.net/sfu/intel-dev2devmar
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
