> 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
