linux-kernel - Re: New filesystem for Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49A4FD51.6000501@slax.org>
Date:	Wed, 25 Feb 2009 09:12:01 +0100
From:	Tomas M <tomas@...x.org>
To:	Theodore Tso <tytso@....edu>, Tomas M <tomas@...x.org>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux kernel

>> I suggest to remove unionfs from Andrew's -mm tree and replace it by aufs2!
>> Tell me why this should not happen...
> 
> Um, you need to tell us why aufs2 is better than Unionfs.  The burden
> of proof rests on your shoulders.

I understand and agree.

At the time Slax switched from unionfs to aufs, there were the following issues:
(unionfs people are welcome to comment on what's improved in newest unionfs 2.x)

1) Better branch manipulation in aufs
- unionfs used ioctls to manipulate branches, aufs used remount. I do not quite understand which one was better, but remount didn't need any special binary to manipulate branches so that was better for me.

I guess unionfs switched to remount too; not because it is better, but because it was needed just to get mainlined. From my point of view, they do many things just because they desperately need to be mainlined, even if they would like to do it differently (the ioctl branch manipulation is just an example)

2) More branches in one aufs union
- unionfs supported (if I remember correctly) only 128 branches. Aufs supported 1024 branches and if there was an option to support 32767 branches (didn't test it though).

3) Fully working mmap support in aufs
- unionfs wasn't even able to mount a loop file from the union. At the time of my switch, there were no mmap support in unionfs at all. I think they already implemented it, re-using aufs's method.

4) Persistent inode support in aufs
- I'm not sure if I remember this correctly. In unionfs, when a branch was added, I believe that all the inode numbers changed. That had fatal impact on many programs, since it is not supposed to happen. Aufs maintain persistent inode numbers just perfectly.

5) Better stability in aufs
- it is always said that this is a subjective issue. In my opinion, it's pretty objective. Unionfs didn't work well in the past, and they keep fixing race conditions all the time, even now in -mm tree. Aufs simply worked, and it still simply works. I do not remember any single system freeze with aufs, but I remember a lot of freezes with unionfs.

6) Branch information through /sys instead of /proc/mounts
- imagine you added 1000 branches, what happens with your /proc/mounts with unionfs? In aufs, it's just OK.


Tomas M
slax.org


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/