Re: [LSF/MM ATTEND] Stackable Union Filesystem Implementation

[Jan Kara <jack@suse.cz>]

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@suse.cz>
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