Hi,
afr0ck wrote:
Suppose i had a UFS-like filesystem (The inode contains direct and indirect pointers to data blocks and file specific informations like access rights, creation time, owner ... etc) and i wanted to add a functionality to support the fragmentation of the last block. I mean, if the file doesn't fill the last block (Uses only a fraction of it - Only some few bytes are written at the end) then instead of allocating a whole block for it, we only allocate a fragment. The system should not keep a pre-allocated pool of free fragments but whenever a file asks for a fragment we can take a free block and divide it into fragments and use one of them. Of course, other fragments from the same block could be assigned to other files. The other fact is that the number of fragments per block is configurable at the moment of installing the filesystem (The fragment has a fixed size). The problem is that i can't figure out what is the best change or structure that i should give to the inode to support such a functionality ? So what do you propose for that ?
Assume you have a file system on an older hard disk and you copy the entire partition to a newer SSD using something like "dd" to copy raw data from "/dev/hda1" to "/dev/hdb2". This should work (you should be able to copy file systems like this).
Next assume that the file system was on an older hard disk with 512-byte sectors and the file system originally used a 512-byte block size; but you copied it (using something like "dd") to a newer SSD that happens to have a 4096-byte block size. This should work too (you should be able to copy file systems like this, even if the physical sector size is different), it just might not be 100% optimal for performance. Of course in this case you'd hope that the file system code would allocate "groups of 8 blocks" for new files to improve performance.
Essentially; there's a logical block size (that the file system uses) and a physical block size (that the underlying storage device provides), and these can be quite different. The physical block size is nothing more than an optimisation hint; and (if you really wanted to) you could choose any logical block size you want; including using 3-byte blocks, or 100-byte blocks, or anything else; and it shouldn't effect anything except performance.
Now; what is the real difference between "8192-byte blocks where file system may be split a block into 64-byte fragments" and "64-byte blocks where file system might allocate groups of 128 blocks for performance reasons"? In both cases the file system would be able to allocate individual 64 byte pieces - the only real difference is that the first has to have extra code to manage fragments while the second only manages blocks and doesn't have any extra code that shouldn't already be there.
In other words; why bother with fragments when you can just reduce the block size instead?
Cheers,
Brendan