[LSF/MM ATTEND] Stackable Union Filesystem Implementation

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

 



I would like to attend LSF/MM summit. I will like to discuss approach
to be taken to finally bring up a Union Filesystem for Linux kernel.

My tryst with Union Filesystem began when I was involved developing a
filesystem as a part of  GSOC2013(Google Summer of Code) for CERN
called Hepunion Filesystem.

CERN needs a union filesystem for LHCb to provide fast diskless
booting for its nodes. For such an implementation, they need a file
system with two branches a Read-Write and a Read Only so they decided
to write a completely new union file system called Hepunion. The
driver was  partially completed and worked somewhat with some issues
on 2.6.18. since they were using SCL5(Scientific Linux),

Now since LHCb is  moving to newer kernels, we ported it to newer
kernels but this is where the problem started. The design of our
filesystem was this that we used "path" to map the VFS and the lower
filesystems. With the addition of RCU-lookup in 2.6.35, a lot of
locking was added  in kernel functions like kern_path and made our
driver unstable beyond repair.

So now we are redesigning the entire thing from scratch.

We want to develop this Filesystem to finally have a stackable union
filesystem for the mainline Linux kernel . For such an effort,
collaborative development and community support is a must.


For the redesign, AFAIK
I can think of two ways to do it-

 1. VFS-based stacking solution- I would like to cite the work done by
Valerie Aurora was closest.

 2. Non-VFS-based stacking solution -  UnionFS, Aufs and the new Overlay FS

Patches for kernel exists for overlayfs & unionfs.
What is  communities view like which one would be good fit to go with?

The use case that I am looking from the stackable filesystem is  that
of "diskless node handling" (for CERN where it is required to provide
a faster diskless
booting to the Large Hadron Collider Beauty nodes).

 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.

Thus to design such a fileystem I need community support and hence
want to attend LSF/MM summit.

  Regards,
  Saket Sinha

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]