linux-kernel - Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

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]

Date:	Sat, 16 Mar 2013 22:55:53 +0900
From:	"J. R. Okajima" <hooanon05@...oo.co.jp>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, hch@...radead.org, apw@...onical.com,
	nbd@...nwrt.org, neilb@...e.de, jordipujolp@...il.com,
	ezk@....cs.sunysb.edu, dhowells@...hat.com,
	sedat.dilek@...glemail.com, mszeredi@...e.cz
Subject: Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

Al Viro:
> Sure - btrfs happens to have an interesting limit on the number of
> links to the same object located in one directory.

It doesn't matter.
On every filesystem, the link count has its upper limit eventually. When
vfs_link() for whiteout returns EMLINK, aufs removes the whiteout-src
file and creates a new one internally and asynchronously. Completing a
new whiteout-src, aufs will go back to the link approach. The actual
link count when EMLINK returned does not matter.

Some filesystems don't support link(2). For such fs, user should tell
aufs that the layer-fs has no link, and aufs will always create whiteout
as a size-zeroed regular file instead of hardlink. Otherwise user cannot
remove a file logically (rm(1) will return ENOTSUP or EPERM.).

> And yes, it is an independent primitive.  What I really don't understand
> is WTF is so attractive about not having to touch individual filesystems;
> it's not particulary hard to do for any fs we might care about...

Hmm, aufs might have lived too long time as outside mainline. The
whiteout approach aufs took is non-modifying the underlying fs. And I
thought it is essentially important for new fs, otherwise it would be
harder to be merged.

J. R. Okajima
--
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/