On Tue, Aug 6, 2013 at 8:40 PM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: > On Tue, Aug 6, 2013 at 8:36 PM, Sankar P <sankar.curiosity@xxxxxxxxx> wrote: >> On Tue, Aug 6, 2013 at 10:10 AM, Rajat Sharma <fs.rajat@xxxxxxxxx> wrote: >>> Hey buddy, its a good work. You never know how many people you end up >>> helping with this code. I would definitely recommend this as a >>> starter. >>> >> >> Thank you so much :) It feels so nice to hear this from you :) >> >>> One recommendation: add support for page-cache. Start with read-cache >>> only, and then mmap support, you need that to allow binary execution. >>> >> >> oh okay. You suggest that I should do this before I start implementing >> the support for extents ? >> > > Its upto you, but doing that before extents seems more towards basic > tutorial steps for writing a filesystem. > Okay. I do not much about page cache. I will read about it. I think it is better if I implement the page cache support so that I can cache better. Good caching will help in working with big files once extent support is implemented (iiuc) Thanks for your suggestions :) Sankar >> Sankar >> >>> -Rajat >>> >>> On Tue, Aug 6, 2013 at 12:27 AM, Sankar P <sankar.curiosity@xxxxxxxxx> wrote: >>>> Hi, >>>> >>>> For learning purposes, I thought I would implement a filesystem from >>>> the scratch. It has reached a state where I can do a 1.0 release. >>>> >>>> The sources are at: https://github.com/psankar/simplefs >>>> >>>> The layout is simple. The first (zeroth) block is the superblock and >>>> contains information like fs magic, number of inodes, freeblock map >>>> etc. The next block is the inode store. Creation of files and >>>> directories is supported. Nested directories are supported. A file can >>>> grow up to one block only. The data blocks for a directory contain the >>>> filename and inode number of its children. For files, it will >>>> obviously contain the actual data of the file. There are three >>>> rudimentary locks to make sure the accesses are thread safe. >>>> >>>> The 1.0 version is filled with a lot of TODOs and memory leaks. Also >>>> while implementing this, I realized that it is a bad idea to maintain >>>> the superblock and the freeblock store together in a block. So I am >>>> planning to change the on-disk layout in the next version. >>>> >>>> Apart from moving the super block to minimize locks, I am planning to >>>> implement support for extents in the next version, and journalling in >>>> the next-to-next version. The next version will take some time to >>>> come, though. But if someone wants to try filesystems from the >>>> scratch, I thought it may be useful if I share the link now itself. >>>> >>>> Also, I take this moment to thank the kernelnewbies list, especially >>>> the regular people like Mulyadi Santosa, Valdis Kletnieks, Rajat >>>> Sharma, Greg Freemyer etc. Also I would like to thank Neha Naik, >>>> Manish Katiyar who helped me with some queries during this particular >>>> implementation. I saw that Manish Katiyar has also done a similar >>>> from-the-scratch implementation and it motivated me to pursue further. >>>> >>>> Any feedback on the code is welcome. Although, I want to inform that I >>>> plan to change the locking until after I decide on a good on-disk >>>> layout for the next version, which will by-design minimize the locking >>>> needs, by splitting out freestore from superblock, keep track of >>>> children inode in a better way etc. Also I have been resisting the >>>> urge to look at ext or any other filesystem's design so as to not skew >>>> my thoughts and go with a fresh state of mind and get my own design :) >>>> >>>> Thanks. >>>> >>>> -- >>>> Sankar P >>>> http://psankar.blogspot.com >>>> >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> >> >> -- >> Sankar P >> http://psankar.blogspot.com -- Sankar P http://psankar.blogspot.com _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
