Has anyone successfully designed a filesystem that doesn't wast space in sectors? Like the 1 byte file that wast 511 bytes in a sector. If so, did they figure out a way to do this fast enough that users don't really know a difference?
Also just a small poll, whats your favorite filesystem and why?
Filesystems
Re:Filesystems
oh yeah 
but, before you start thinking about how not to get it, think about why you did get it in the first place. It was not done because it was a simple way so save some bits in the file tables. It was done so that if your file grew, it would have space to grow without allocating another block of disk space.
Now you know why, attack the part where the system is effective, but not successful. For the files that do not grow, it's a waste. Nowadays, with hundred-gigabyte harddisks, there are lots of files (thousands to possibly millions) that will never be written to. Yet they waste disk space. For the worst examples, try unpacking source to a fat16 harddisk of 2G or something similar.
Then how to do so efficiently? Well, not the simple way of allocation by the byte. That could increase the amount of sector reads you need for a file.
But, if you store all but the last (incomplete) block in a normal set of blocks, possibly large ones (64K? 1M?) and then use one of the predefined space-section blocks for the end section (which can be shared), then you do not have the problem of slack space. Also, because the last sector is forced to fit in a single block (if it doesn't fit, allocate a new block for it), you still get the same performance as with normal filesystems.
My favorite filesystem? Based on what?
On functionality: NTFS
On usability: ext3
On speed: ReiserFS
On all, but availability: my own
BTW, there already is an FS concept thread in quicklinks, look there and post there. Pype, could you move these there too ?
but, before you start thinking about how not to get it, think about why you did get it in the first place. It was not done because it was a simple way so save some bits in the file tables. It was done so that if your file grew, it would have space to grow without allocating another block of disk space.
Now you know why, attack the part where the system is effective, but not successful. For the files that do not grow, it's a waste. Nowadays, with hundred-gigabyte harddisks, there are lots of files (thousands to possibly millions) that will never be written to. Yet they waste disk space. For the worst examples, try unpacking source to a fat16 harddisk of 2G or something similar.
Then how to do so efficiently? Well, not the simple way of allocation by the byte. That could increase the amount of sector reads you need for a file.
But, if you store all but the last (incomplete) block in a normal set of blocks, possibly large ones (64K? 1M?) and then use one of the predefined space-section blocks for the end section (which can be shared), then you do not have the problem of slack space. Also, because the last sector is forced to fit in a single block (if it doesn't fit, allocate a new block for it), you still get the same performance as with normal filesystems.
My favorite filesystem? Based on what?
On functionality: NTFS
On usability: ext3
On speed: ReiserFS
On all, but availability: my own
BTW, there already is an FS concept thread in quicklinks, look there and post there. Pype, could you move these there too ?
-
darklife
Re:Filesystems
Great information! Thank you. I have some ideas for my own
file system but there a little complex to describe in a short post. One of my ideas is to not have directories be "special" files like most file systems do, but instead to have a big file containing ALL the directory entries. Each entry would have its own special ID, and files would be linked to that ID. Any file that points to a specific directory ID would belong to it. This makes it much easier to move files and directories around! To move a file to another directory, all I have to do is change its Dir ID link. I hope that makes sense. The wasted disc space problem has been driving me nuts simply because I would like to overcome this limitation.
Maybe most of my ideas not mentioned already exist. Time to go study..
file system but there a little complex to describe in a short post. One of my ideas is to not have directories be "special" files like most file systems do, but instead to have a big file containing ALL the directory entries. Each entry would have its own special ID, and files would be linked to that ID. Any file that points to a specific directory ID would belong to it. This makes it much easier to move files and directories around! To move a file to another directory, all I have to do is change its Dir ID link. I hope that makes sense. The wasted disc space problem has been driving me nuts simply because I would like to overcome this limitation.
Maybe most of my ideas not mentioned already exist. Time to go study..
-
darklife
Re:Filesystems
Answer to my own poll...
-FAT16 because it's so easy to understand and quick to implement.
-ext2 since my host OS uses it
-FFS because I have always liked the Amiga.
The list is short because I haven't yet studied most other file systems.
-FAT16 because it's so easy to understand and quick to implement.
-ext2 since my host OS uses it
-FFS because I have always liked the Amiga.
The list is short because I haven't yet studied most other file systems.
-
Curufir
Re:Filesystems
You might enjoy reading the Reiser4 white paper http://www.namesys.com/. It gives a decent insight into many of the problems/failings/solutions that relate to a modern file system.
Re:Filesystems
Unless I'm mistaking, you're fixing a problem that's not even there. You want to make moving files + directories easier? that is already easy enough in unix-ish filesystems. You add a link to the inode in the place where you want it, then unlink it from its old place. Enddarklife wrote: One of my ideas is to not have directories be "special" files like most file systems do, but instead to have a big file containing ALL the directory entries. Each entry would have its own special ID, and files would be linked to that ID. Any file that points to a specific directory ID would belong to it. This makes it much easier to move files and directories around! To move a file to another directory, all I have to do is change its Dir ID link. I hope that makes sense.
That doesn't really allow much speedups. Also, in your case, how will you know the end of a directory? And, combined with the other method I mentioned, how is it even a bit better?
-
darklife
Re:Filesystems
I do understand the Unix file system and "those" file systems work very nice IMHO. I didn't realize I was "fixing a problem that's not even there"Candy wrote:
Unless I'm mistaking, you're fixing a problem that's not even there. You want to make moving files + directories easier? that is already easy enough in unix-ish filesystems. You add a link to the inode in the place where you want it, then unlink it from its old place. End
I just had the idea and wanted to try it.The more I think about it now the more I understand how my idea wouldn't be of good use.That doesn't really allow much speedups. Also, in your case, how will you know the end of a directory? And, combined with the other method I mentioned, how is it even a bit better?
Knowing the end of a directory using my method would be as simple as reading the directory entry.
It probably isn't any better. Since my last post, I have come up with MUCH BETTER ideas. Hey, we all come up with unsuitable ideas sometimes ;D
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Filesystems
I'm not sure, but i think NTFS roughly has similar implementation ... i should check Tanenbaum's article about NTFS again ...darklife wrote: One of my ideas is to not have directories be "special" files like most file systems do, but instead to have a big file containing ALL the directory entries.
I'm not really convinced by "one big list for all directories" for following reasons:
- how will you keep logical directories structure ? linked list saying in each entry 'next entry is ...' ?
- it doesn't look like reducing the head movements, but rather will tend to increase it as logically close items (i.e. files within one directory
- as you'll have all the mess of all the directories at one single place, this will lead to an increased fragmentation, more scattered entries for one directory, etc.