100 likes | 251 Views
HEPUNION FILE SYSTEM. SAKET SINHA (saket.sinha89@gmail.com) Mentors- Loic Brarda Pierre Schweitzer. Introduction.
E N D
HEPUNION FILE SYSTEM SAKET SINHA (saket.sinha89@gmail.com) Mentors- Loic Brarda Pierre Schweitzer
Introduction • Hepunion Filesystem-combines the namespaces of two or more file systems together to produce a single merged namespace. i.e. presents a series of directories from different file systems as one virtual directory . Uses of Hepunion Filesystem • Providing disk-less boot for a huge computing facility.
Hepunion Filesystem in Kernel • Plan 9 has union directories for merging only the top-level directory namespace. BSD has used union filesystem from its earliest versions. • Linux does not still have a union file system with over 22 years of existence since it does not support Stackable filesystem. • Stackable filesystem behave as both a file system(for the vfs) and the VFS(for lower filesystems).
GSOC Goals & Archeivments Before GSOC- • Filesystem Driver was unstable on 2.6.18. • Needed to be ported to newer kernel versions GSOC Goals • Port to 3.8 kernel. • Make the driver stable Achievements • Successfully ported to 3.8 kernel with- 10 changed files 841 additions 629 deletions • While solving the driver instability, we found a design issue with the filesystem on newer kernels.
Hepunion FS- Instability Point • In the mount pointa simple "ls" command hangs the kernel. • Several Debugging Technique were used 1.Live kernel Debugging with KDB 2. CrashDump 3.Throwing kernel messages at Serial port
Results after Debugging • The last function before hang was kern_path. • The last dmesg log before the hang was- [ 524.188183] BUG: soft lockup - CPU#0 stuck for 23s! • When the kernel was stuck following message kept repeating itself in an endless loop- [ 524.188258] [<ffffffff81085bfa>] lg_local_lock+0x1a/0x20 CONCLUSION- In function kern_path, a soft lockup is occurring due to lg_local_lock, the in-kernel lock validator.
How does “ls” get lg_local_lock? • Suppose there are ten functions, each function call the other function like 1->2->3->4..->10. If function 1 takes the lock X and now function 6 also tries to take the same lock X, so function 6 will wait....infinitely. That’s DEADLOCK • Same is the case with path_init(which takes lock) on issuing “ls”
Why do we need kern_path? • Why does hepunion_permission uses kern_path ? • This is our filesystem design. With this design we have to use kern_path at all cost.
READ COPY UPDATE (RCU) change in VFS • Rcu-walk faster way to perform internal file operations. • With RCU from 2.6.35, kernel locking rules were redefined. • Linus Torvalds paused the kernel merge window for several days when making this change. To quote him “It's scary because this is some very core code.”
What is the real design issue • In our filesystem, like any other stackable filesystem, attributes may be OUT OF SYNC between the merged layer and RW/RO branch. • This means that if RW/RO branch attributes are modified, the merged layer does not reflect those changes. • PERSISTENT MAPPING between HIGHER & LOWER layer is a must. PRESENT APPROACH • Comparing relative path in RW/RO branch with real path registered with VFS. • With new RCU walk in VFS, new locking rules do NOT allow this. PROPOSED APPROACH 1. Unused Fields and Bits of Inodes 2. Parallel Filesystem 3. Extended attributes