simplefs - a ridiculosly simple file system from the scratch
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
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. One recommendation: add support for page-cache. Start with read-cache only, and then mmap support, you need that to allow binary execution. -Rajat On Tue, Aug 6, 2013 at 12:27 AM, Sankar P <sankar.curiosity@gmail.com> 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Aug 6, 2013 at 10:10 AM, Rajat Sharma <fs.rajat@gmail.com> 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 ? Sankar
-Rajat
On Tue, Aug 6, 2013 at 12:27 AM, Sankar P <sankar.curiosity@gmail.com> 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sankar P http://psankar.blogspot.com
On Tue, Aug 6, 2013 at 8:36 PM, Sankar P <sankar.curiosity@gmail.com> wrote:
On Tue, Aug 6, 2013 at 10:10 AM, Rajat Sharma <fs.rajat@gmail.com> 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.
Sankar
-Rajat
On Tue, Aug 6, 2013 at 12:27 AM, Sankar P <sankar.curiosity@gmail.com> 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sankar P http://psankar.blogspot.com
On Tue, Aug 6, 2013 at 8:40 PM, Rajat Sharma <fs.rajat@gmail.com> wrote:
On Tue, Aug 6, 2013 at 8:36 PM, Sankar P <sankar.curiosity@gmail.com> wrote:
On Tue, Aug 6, 2013 at 10:10 AM, Rajat Sharma <fs.rajat@gmail.com> 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@gmail.com> 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sankar P http://psankar.blogspot.com
-- Sankar P http://psankar.blogspot.com
On Tue, Aug 6, 2013 at 11:06 AM, Sankar P <sankar.curiosity@gmail.com> wrote:
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 ?
Sankar
Sankar, Do a strace on just about any program and you will see mmap is used heavily. Extents is an internal nicety, but mmap is core functionality that you would need even on a simpleFS for an embedded system. Greg -- Greg Freemyer
On Wed, Aug 7, 2013 at 6:07 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Tue, Aug 6, 2013 at 11:06 AM, Sankar P <sankar.curiosity@gmail.com> wrote:
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 ?
Sankar
Sankar,
Do a strace on just about any program and you will see mmap is used heavily. Extents is an internal nicety, but mmap is core functionality that you would need even on a simpleFS for an embedded system.
I just read your todo's. Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based filesystems. ext4 is the first extent based one. So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports. If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step. For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that. With just those todo's I go in this order: - lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely. Greg
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Wed, Aug 7, 2013 at 6:07 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
On Tue, Aug 6, 2013 at 11:06 AM, Sankar P <sankar.curiosity@gmail.com> wrote:
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 ?
Sankar
Sankar,
Do a strace on just about any program and you will see mmap is used heavily. Extents is an internal nicety, but mmap is core functionality that you would need even on a simpleFS for an embedded system.
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based filesystems. ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response. I will go in this order as this seem to be logically progressive nicely iiuc. When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ? Thanks. -- Sankar P http://psankar.blogspot.com
Sankar P <sankar.curiosity@gmail.com> wrote:
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote: <snip>
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based
filesystems.
ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response.
I will go in this order as this seem to be logically progressive nicely iiuc.
When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ?
Thanks.
I've never done a FS from scratch so I'm not sure, but I would delay them as long as you can. I suspect you will need cache support to properly handle writes on a multi block file, so as you work on that feature you may decide "now is the time" for the cache. Mmap should be last. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
okay. Thanks. I will update this list once I write enough code for the next release :) On Thu, Aug 8, 2013 at 4:59 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Sankar P <sankar.curiosity@gmail.com> wrote:
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote: <snip>
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based
filesystems.
ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response.
I will go in this order as this seem to be logically progressive nicely iiuc.
When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ?
Thanks.
I've never done a FS from scratch so I'm not sure, but I would delay them as long as you can.
I suspect you will need cache support to properly handle writes on a multi block file, so as you work on that feature you may decide "now is the time" for the cache.
Mmap should be last.
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sankar P http://psankar.blogspot.com
Hi Sankar, Have you written any code further. I read your file system's code and learnt a lot from it. On Thu, Aug 8, 2013 at 8:36 PM, Sankar P <sankar.curiosity@gmail.com> wrote:
okay. Thanks. I will update this list once I write enough code for the next release :)
On Thu, Aug 8, 2013 at 4:59 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Sankar P <sankar.curiosity@gmail.com> wrote:
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote: <snip>
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based
filesystems.
ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response.
I will go in this order as this seem to be logically progressive nicely iiuc.
When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ?
Thanks.
I've never done a FS from scratch so I'm not sure, but I would delay
them as long as you can.
I suspect you will need cache support to properly handle writes on a
multi block file, so as you work on that feature you may decide "now is the time" for the cache.
Mmap should be last.
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sankar P http://psankar.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Rishi Agrawal
2014-03-28 23:11 GMT+05:30 Rishi Agrawal <rishi.b.agrawal@gmail.com>:
Hi Sankar,
Have you written any code further. I read your file system's code and learnt a lot from it.
Good to know that you have learnt from it. I stopped at a logical closure where the filesystem is at a usable state. I did not write any code further as I am spending my personal time on changing diapers for my newborn :) Whatever little time I get, I tend to do it in trivial user space applications. Extending the filesystem requires long hours of learning, context maintenance, focus etc. So I deferred it for a later stage. I will be happy to get some patches though :)
On Thu, Aug 8, 2013 at 8:36 PM, Sankar P <sankar.curiosity@gmail.com> wrote:
okay. Thanks. I will update this list once I write enough code for the next release :)
On Thu, Aug 8, 2013 at 4:59 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Sankar P <sankar.curiosity@gmail.com> wrote:
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <greg.freemyer@gmail.com> wrote: <snip>
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based
filesystems.
ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response.
I will go in this order as this seem to be logically progressive nicely iiuc.
When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ?
Thanks.
I've never done a FS from scratch so I'm not sure, but I would delay them as long as you can.
I suspect you will need cache support to properly handle writes on a multi block file, so as you work on that feature you may decide "now is the time" for the cache.
Mmap should be last.
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sankar P http://psankar.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Rishi Agrawal
-- Sankar P http://psankar.blogspot.com
On Sat, Mar 29, 2014 at 4:31 PM, Sankar P <sankar.curiosity@gmail.com>wrote:
2014-03-28 23:11 GMT+05:30 Rishi Agrawal <rishi.b.agrawal@gmail.com>:
Hi Sankar,
Have you written any code further. I read your file system's code and learnt a lot from it.
Good to know that you have learnt from it. I stopped at a logical closure where the filesystem is at a usable state.
I did not write any code further as I am spending my personal time on changing diapers for my newborn :)
Whatever little time I get, I tend to do it in trivial user space applications. Extending the filesystem requires long hours of learning, context maintenance, focus etc. So I deferred it for a later stage. I will be happy to get some patches though :)
On Thu, Aug 8, 2013 at 8:36 PM, Sankar P <sankar.curiosity@gmail.com>
wrote:
okay. Thanks. I will update this list once I write enough code for the next release :)
On Thu, Aug 8, 2013 at 4:59 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
Sankar P <sankar.curiosity@gmail.com> wrote:
On Thu, Aug 8, 2013 at 3:55 AM, Greg Freemyer <
greg.freemyer@gmail.com>
wrote: <snip>
I just read your todo's.
Multi-block files should come before extents and/or mmap support. I guess you realize that ext2 and ext3 are NOT extent based
filesystems.
ext4 is the first extent based one.
So its: ext2 - block based filesystem ext3 - block based with a journal ext4 - extent based with a journal
In reality the current ext4 driver has a matrix of supported features. There are flag bits which tell you which features a specific filesystem instance supports. You may want to atleast look at those feature flags to get an idea of the kinds of features ext4 supports.
If you don't have lseek() support for read, you need to get it added. lseek() is pretty trivial for reads so there is not much reason not to have it as the very next step.
For write, it means you have to implement a read/modify/write cycle in your filesystem. I gather you don't have that.
With just those todo's I go in this order:
- lseek() support with read (trivial) - partial block write support (requires read/modify/write logic, so not trivial) - lseek() support for write (trivial now you have partial block write support) - multi-block support, requires a major refactor most likely.
Thank you so much for the detailed response.
I will go in this order as this seem to be logically progressive nicely iiuc.
When do you think I should bring in support for mmap and page-caching that Rajat in the above plan ?
Thanks.
I've never done a FS from scratch so I'm not sure, but I would delay them as long as you can.
I suspect you will need cache support to properly handle writes on a multi block file, so as you work on that feature you may decide "now is the time" for the cache.
Mmap should be last.
Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-- Sankar P http://psankar.blogspot.com
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Regards, Rishi Agrawal
-- Sankar P http://psankar.blogspot.com
I identified one memory leak while reading the code. Will send the patch. -- Regards, Rishi Agrawal
participants (4)
-
Greg Freemyer -
Rajat Sharma -
Rishi Agrawal -
Sankar P