From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: [overlayfs/port] overlayfs: v13 port attempt to kernel 3.5 Date: Mon, 20 Aug 2012 19:38:18 +0900 Message-ID: <8326.1345459098@jrobl> References: <20120816204440.GA8808@ymail.com> <20120817010519.GA2440@ymail.com> Cc: Andrew Watts , Linus Torvalds , linux-fsdevel@vger.kernel.org, LKML , Daniel Baumann To: sedat.dilek@gmail.com Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Sedat Dilek: > The other part to run a Linux live-system is a "Union FileSystem" - > this part is missing (speaking of upstream). > > Since years AUFS seems to be the choice #1 in a lot of distros to > workaround the problem. > NOTE: AUFS was rejected from upstream (to say not accepted). Exactly. The reason was that linux rejects all union-type filesystems but UnionMount (which is union-type mount). Later, the development of UnionMount seems to be almost stopped. The essential design of overlayfs is based upon UnionMount, and I have pointed out several issues such as - for users, the inode number may change silently. eg. copy-up. - hardlinks may break by copy-up. - read(2) may get an obsoleted filedata (fstat(2) for metadata too). - fcntl(F_SETLK) may be broken by copy-up. - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after open(O_RDWR). - Later I noticed one more thing. /proc/PID/{fd/,exe} may not work correctly for overlayfs ... - etc... They are called "unPOSIXy behavior", and unforunately many of them are NOT seem to be addressed in recent patches either. Also I have posted If the development of UnionMount is really stopped, then I'd ask people to consider merging aufs as well as overlayfs. but I am not sure whether LKML people are still waiting for UnionMount and rejecting aufs. J. R. Okajima