Wednesday 03 October 2007, Sergej Pupykin wrote:
| As I know, jfs place very small files directly into directory.
|
| reiserfs places file tails in single B+ tree with directory
| entries and inodes.
|
| ext2 split disk to cylinder group. but I'm not sure how it
| searches empty space.
|
| "same" does not mean allocation groups like xfs, but spreading
| files over the disk.
|
| Flash file systems like jffs spread files specially...
thanx
| It is hardly to place files together I think...
hmm... what i tried is a loop device of a fixed size (100mb) on the
directory that contains small files. it works fine, but is a little
bit of a pain changing size.
conceptually seen, small files should not be stored plainly on the fs.
one idea would be to have the fs to decide what is small file what a
big file and what has the potential to fragment and then on the back
reshuffle things and change strategy of storage to optimise access.
it would be like a library or an archive (with books in it - the real
library kind of library *g*) where the people working there sort
things by its properties. if single papers are filed, they end in
folders. if encyclopedias are filed, whole shelfs are reserved for
them. if a paper develops in an encyclopedia, then the person working
there changes things. the CPU's nowadays are capable of providing the
power (in the background) to do such intelligence (complex
algorithms) but i am not aware of an implementation on the fs-level.
there are some sql-like database-like approaches (winfs?) but this is
still not facing the problem directly.
we need to employ somebody to tell the fs driver where to store
things... anybody knows a librarian with free time? 'Oook' :)
- D
--
.·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´
° ° °
° ° °
><((((º> ° °
° °
° <º)))><
<º)))><
_______________________________________________
arch mailing list
[email protected]
http://archlinux.org/mailman/listinfo/arch
