Thank you for the response. I suspect this is primarily an algorithm
issue. The aufs directory read takes about 1 minute if the SSD
directory has 10,000 files. It takes only 30 seconds if the SSD
directory has 5000 files. It takes 1 second if the SSD directory has
100 files. Does aufs look at the
TualatriX,
Here is a patch for ramfs branch.
Although I am testing it now, try testing it if you have time.
Note: you need to enable CONFIG_AUFS_BR_RAMFS.
Completing ramfs branch, I will try readonly aufs branch.
Here is a patch for 'robr'.
Please test it too.
You need to enable
Hi,
Nitin Bhardwaj:
I noticed that when I first use mount.aufs for the first union, it
replaces the soft link /etc/mtab with a real separate file /etc/mtab.
Meaning, the /etc/mtab is no longer a soft link now and two lines get
added for the single mount and the last line has extraneous
: Can I reproduce it?
: How did you load the module, insmod/modprobe manually, or modprobe
: automatically?
I can reproduce it every time on all my systems. I know the ones that
actually call modprobe manually have the problem (either in a script
or some other way). I'll have to look for ones
Ryousei Takano:
I got the error message described below, when I issued umount.
It seems hasmntopt(3) does not work properly.
What is happen?
$ mkdir /tmp/a /tmp/b /tmp/c
$ sudo mount -t aufs -o br=/tmp/a:/tmp/b=ro none /tmp/c
$ sudo umount /tmp/c
Nitin Bhardwaj:
Yes, I'm still using aufs 20080428 and /sbin/mount.aufs as is it...
Here are the debug outputs; The error comes in mounting /usr ( file usr.mount
).
Thank you for your tests.
I guess the problem comes from your sed command or busybox.
If you have /bin/sed or something, try
$
Matthew Harrell:
It looks like all the modules loaded after initramfs are like that including
the ones that were loaded by hal. I load aufs in the initramfs if I find
it and that one's not in the RW partition. On one of the systems I just
removed all of them from the RW partition and
I don't know why the message was produced (it was not OOPS actually). It
looks like there plenty of memory left in your system.
I've found that memory re-allocation complained too large block.
It is another limitation of current aufs. I have to consider...
J. R. Okajima
:
: Are you using aufs2 20090302 with 2.6.21?
:
No, it's aufs1 but the 20090302 source tree. It does identify itself as
20090126 when I load it. Sorry about the confusion
--
Matthew Harrell Never raise your hand to your
Bit Twiddlers, Inc.
I've found that memory re-allocation complained too large block.
It is another limitation of current aufs. I have to consider...
Here is a patch against aufs1 20080128.
Could you test it?
J. R. Okajima
a.patch.bz2
Description: BZip2 compressed data
Here is my suggestion. You can select one of them.
- install /bin/sed too into your initramfs.
- specify '-i' at mounting aufs newly since your /etc/mtab is a symbolic
link.
'-n' option for newly mount is good too.
J. R. Okajima
Hi Okajima-san,
On Apr 2, 2009, at 9:47 PM, sf...@users.sourceforge.net wrote:
Ryousei Takano:
I got the error message described below, when I issued umount.
It seems hasmntopt(3) does not work properly.
What is happen?
$ mkdir /tmp/a /tmp/b /tmp/c
$ sudo mount -t aufs -o
Takano Ryousei:
Please try these things.
- append -DDEBUG when you compile auplink.
- cat /proc/mounts just before unmouting.
And show me the outputs.
When I reinstalled all commands, I got the following errors:
$ sudo mount -t aufs -o br=/tmp/a:/tmp/b=ro none /tmp/c
On Thu, Apr 2, 2009 at 8:23 PM, sf...@users.sourceforge.net wrote:
Here is my suggestion. You can select one of them.
- install /bin/sed too into your initramfs.
- specify '-i' at mounting aufs newly since your /etc/mtab is a symbolic
link.
'-n' option for newly mount is good too.
J.
14 matches
Mail list logo
