From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [LSF/MM ATTEND] Stackable Union Filesystem Implementation Date: Wed, 8 Jan 2014 12:16:40 +0100 Message-ID: <20140108111640.GD8256@quack.suse.cz> References: <20140107122301.GC16640@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kara , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: Saket Sinha Return-path: Received: from cantor2.suse.de ([195.135.220.15]:51342 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754867AbaAHLQn (ORCPT ); Wed, 8 Jan 2014 06:16:43 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed 08-01-14 01:34:47, Saket Sinha wrote: > > So I'm wondering, have you tried using any of the above mentioned > > solutions? I know at least Overlay FS should be pretty usable with = any > > recent kernel, aufs seems to be ported to recent kernels as well. I= 'm not > > sure how recent patches can you get for unionfs. > > >=20 > Several implementations of union file system fusion were evaluated. > The results of the evaluation is shown at the below link- > http://www.4shared.com/download/7IgHqn4tce/1_online.png >=20 > While evaluating union file systems implementations, it became clear > that none was perfect for net booted nodes. > All were designed with totally different goals than ours. >=20 > One of the big problems was that too many copyups were made on the > read-write file system. So we decided to implement an union file > system designed for diskless systems, with the following > functionalities: >=20 > 1. union between only one read-only and one read-write file systems >=20 > 2. if only the file metadata are modified, then do not > copy the whole file on the read-write files system but > only the metadata (stored with a file named as the file > itself prefixed by '.me.') So do you do anything special at CERN so that metadata is often modif= ied without data being changed? Because there are only two operations where= I can imagine this to be useful: 1) atime update - but you better turn atime off for unioned filesystem anyway. 2) xattr update > 3. check when files on the read-write file system can be removed How can that happen? > >Are you missing some functionality? >=20 > The use case of a union type filesystem that I am looking for (CERN) > is diskless clients which AFAIR this can not be done in overlayfs. > Correct me if I am wrong. Well, I believe all unioning solutions want to support the read-only filesystem overlayed by a read-write filesystem. Your points 2. and 3. = is what makes your requirements non-standard. > >> For this we need a > >> 1. A global Read Only FIlesystem > >> 2. A client-specific Read Write FIlesystem via NFS > >> 3. A local Merged(of the above two) Read Write FIlesystem on ramdi= sk. > > I'm not sure I understand. >=20 > Let me answer question one by one to explain > >So you have one read-only FS which is exported to cliens over NFS I= presume. Then you have another client specific > > filesystem, again mounted over NFS. > We first tried to make the union on the nodes during diskless > initialisation but finally choose to do it on the > server, and NFS exports the =E2=80=9Cunioned=E2=80=9D file system. Cl= ient side union > was just using too much memory. >=20 > >I'm somewhat puzzled by the 'read-write' note there - do you mean t= hat the client-specific filesystem > > can be changed while it is mounted by a client? Or do you mean that= the > > client can change the filesystem to store its data? > I mean the client has the permission to change the data and modify it= =2E >=20 >=20 > >And if client can store > > data on NFS, what is the purpose of a filesystem on ramdisk? >=20 > I am sorry for that I wanted to give that as an alternative to the > above approach. Just a typo. > A local Merged(of the above two) Read Write FIlesystem on ramdisk is > something what happens in Knoppix distro where you get an impression > that you are able to change and modify data. OK, that makes sense now. Thanks for explanation. Honza --=20 Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html