1 / 10

HEPUNION FILE SYSTEM

HEPUNION FILE SYSTEM. SAKET SINHA (saket.sinha89@gmail.com) Mentors- Loic Brarda Pierre Schweitzer. Introduction.

neil
Download Presentation

HEPUNION FILE SYSTEM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. HEPUNION FILE SYSTEM SAKET SINHA (saket.sinha89@gmail.com) Mentors- Loic Brarda Pierre Schweitzer

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

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

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

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

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

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

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

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

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

More Related