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. > > > > 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 > > 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. > > 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: > > 1. union between only one read-only and one read-write file systems > > 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 modified 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? > > 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 ramdisk. > > I'm not sure I understand. > > 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 “unioned” file system. Client side union > was just using too much memory. > > >I'm somewhat puzzled by the 'read-write' note there - do you mean that 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. > > > >And if client can store > > data on NFS, what is the purpose of a filesystem on ramdisk? > > 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 -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
