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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>   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.')

3. check when files on the read-write file system can be removed

>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.

>> Patches for kernel exists for overlayfs & unionfs.
>> What is communities view like which one would be good fit to go with?
>   Currently Miklos Szeredi is working on getting his Overlay FS upstream,
> also UnionFS has reasonable chance of getting there eventually. Currently
> both of them are blocked by some VFS changes AFAIK and Miklos is working on
> them.
>
This is what I am looking forward too. I want to know what all exactly
kernel maintainers want from a stackable Union filesystem which they
finally would let into mainline kernel. I even wrote to Al-Viro and
linux-fsdevel community but haven't got any responses. UnionFS and
Aufs have existed for many years outside the mainline kernel with no
signs of ever get included. Recently I have heard a lot about Overlay
Fs too but I even doubt its fate.


>>  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.

Let me list the RHEL way of setting up a diskless server for perhaps
better understanding.
Up to RHEL5, Red Hat had a package named systemconfig-netboot to setup
diskless servers. It was a set of
python and bash scripts that were setting up the dhcpd and tftpd
servers, customising the shared root file system
and making the initial ramdisk for the diskless nodes.

To make some files of the root file system writeable for the nodes,
with possibly different contents, the
initialisation script from this package was making the following
actions after having mounted the root file
system:
• Mount the 'snapshot' directory from the server, in read/write mode.
This directory contains one subdirectory
per node and two files with the list of the files that need to be writable.
• Remount (using the bind mount option) each of these files from the
node's snapshot to the root file system.

There are two problems with this method:
• Only files or folders of the fixed list can be writeable. To add a
file to that list, we have to reboot the nodes
after the file list modification.
• The mount table is 'polluted' by all these remounts.

Our solution: To add flexibility to the diskless nodes handling, we
had the idea of using file system union

>> Thus to design such a fileystem I need community support and hence
>> want to attend LSF/MM summit.
>   So my suggestion would be to try OverlayFS / UnionFS, see what works /
> doesn't work for you and work with respective developers to address your
> needs. We definitely don't need yet another fs-unioning implementation.
>
I am sorry but as all the existing solutions do not completely meet my
use-case mentioned above. Even I do not want to re-invent the wheel
but  I have mentioned above the reasons why we went for a new
solution.

Regards,
Saket Sinha
--
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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux