UNIX file system fragmentation
|
|
|
Comments (1)
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post

I mean, SGI had "EFS" in the late 80s, which was basically FFS which stored blocks in extents rather than the block number/indirect blocks/doubly-indirect blocks that FFS had at the time. SGI was dumb enough to include a nearly bug-free defragementer, and a default cron entry that ran it once a week, rather than doing an MSFT and originally releasing NT without a working defrag, or even a documented defragmentation interface.
"Fragments" in FFS (and I believe EXT2) are the smaller-than-a-single-block pieces that might exist at the end of a file. Files bigger than a certain number of bytes are guaranteed to be "fragmented" in the NTFS sense.
"Fragments" in NTFS are files that didn't get allocated in contiguous runs of blocks, so the file header has to have more than 1 extent in it, right?
This article misses that distinction entirely, and thus seems to me to get the whole thing wrong.