On Wed December 2 2009, [email protected] wrote: > > xavi kpan: > > Dear all: > > > > We use aufs to mount an ro rootfs(/usr/,/lib/...) and a writable layer > > on it. both are ext3. > > The lmbench show that creation of file, deteting of files are only a > > half of the speed of the ext3. > > Any suggestion of it? > > > > And Since the the rootfs is readonly, could I change it to squashfs to > > accelerate the read performance? > > > > Best Regards > > > > -- > > a fan of Barcelona and Linux > > Hello xavi, > > If you expect aufs to enhance the speed of filesystem, maybe you are > wrong. Essentially aufs is an overhead of filesystem layers. But I am > tyring minimize the overhead and aufs has some configurations for that. > Read the aufs manual and configure, specify the options, then you will > get the best performance. > > Squashfs is also an overhead because it decompress the contents of fs. > Generally every overhead has its pros and cons. In squashfs, you pay the > cpu cycles for decompression, but you get more disk space, for instance. >
I am guessing here, since xavi did not say "on what" device the "slow read-only" filesystem is on. But I think I understand the question... If the file system is stored on Flash Memory, some Flash Memory is very "slow" - For instance - A) Without file system compression (perhaps squashFS), reading a file might mean reading 4 flash memory pages - B) With file system compression, reading that same file might mean only reading 1 flash memory page *plus* the time to decompress the file - So there are situations, depending on the part characteristics, where "B" is faster than "A" *Plus* some systems with "slow flash" also have available hardware decompression. The combination can make the difference between "B" and "A" a very big difference. (I am currently working with such a system.) The case for auFS in a device with flash based memory also can have a large advantage, even though it increase the number of cpu cycles in the file system layer. That happens for small alterations to files stored on flash. Flash *reads* in pages but only *updates* in erase blocks - usually, 32 or 64 pages. So using auFS to capture the *writes* in a ram based layer (say, tmpFS) and treating the file system as "read-only" can be a system file operation time saving, even though using more cpu cycles in the auFS layer. In such a system, the system designer will normally wait until enough time passes (age) or enough changes accumulate to only then do a "copy down" underneath auFS. If lucky, they might only have to write a single erase block (the minimum update) to get everything that has happened, recorded in flash. One way to make this happen more often than not, is to put the variable files into a size limited file system, either writable or true read-only - something that in compressed form occupies (Y * (erase block size)) (think of any "loop" mounted file system). If a true, read-only system (such as squashFS) this mean reading the old copy, making the auFS captured changes, creating a new copy (updating the minimum number of flash blocks), and then "switching copies". Now that sounds time consuming, it is, but writing changes scattered over many erase blocks in flash is very, very, very slow - regardless of how fast the part is. So this thread subject is a very reasonable one to be asking - Only there is no answer other than "test your system, yourself" - to many variables to even guess at what the overall performance difference might be. There is at least one, low cost (<$100USD) system, also available in Japan, that makes a good example of such a system: the ASUS O!Play, Media Player. Which also has a community, system's development, web-site: http://MiniModding.com run by (guess who). ;) Mike ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev
