Posted by: Anonymous Coward
on October 16, 2003 02:12 AM
I understand why the ancient FAT system requires it, but I completely fail to understand why Microsoft's serious attempt at a new journalled filesystem, NTFS, still requires it. Lack of skill?
For starters, NTFS isn't really all that "new" - it has clearly discernable roots in DEC's old <A HREF="http://h71000.www7.hp.com/wizard/wiz_2678.html" TITLE="hp.com">ODS2/Files-11 VMS filesystem</a hp.com>. Those roots include the format of inode-analogs ("file headers" for ODS2, "file records" for NTFS) storing the inode-analogs in a file ($MFT in NTFS) and <A HREF="http://www.ntfs.com/ntfs-mft.htm" TITLE="ntfs.com">allocating disk blocks for a given file in extents</a ntfs.com> (starting block number, number of contiguous blocks) rather than on a block-by-block basis as say Ext2fs or the BSD FFS. Note that nothing keeps FFS code or Ext2fs code from allocating a file's disk blocks contiguously, just that the on-disk structures don't require it. NTFS and ODS2 store a file's disk blocks as extents.
More to the point: non-log-structured filesystems that allocated a file's disk blocks in extents have always seemed to require defragmenting for some reason. Back in the day, Raxco and Executive software sold defragmenter software for VMS. SGI's Irix used to use a filesystem called "EFS" that resembled FFS but allocated in extents rather than block-by-block. SGI shipped Irix with a defragmenter and a root crontab entry that ran it weekly (as I recall). I've never had a clear idea of why extent-based filesystems require this, but perhaps it's an analog of malloc algorithms like buddy system or first fit that end up leaving a lot of unallocatable "holes" in the heap.
The <A HREF="http://www.winntmag.com/Articles/Index.cfm?IssueID=20&ArticleID=304" TITLE="winntmag.com">history of NTFS defragmenters</a winntmag.com> seems a bit questionable as well. Microsoft clearly threw a bone to Executive Software - allowing them to basically write the native API defragmenting calls, which gave Diskeeper a big leg up on any potential competitors. This is the uncompetitive behavior that should (but never does) get MSFT in trouble.
Learn about Linux
Download Linux
Get Linux help
Re:Defragmentation
Posted by: Anonymous Coward on October 16, 2003 02:12 AMFor starters, NTFS isn't really all that "new" - it has clearly discernable roots in DEC's old <A HREF="http://h71000.www7.hp.com/wizard/wiz_2678.html" TITLE="hp.com">ODS2/Files-11 VMS filesystem</a hp.com>. Those roots include the format of inode-analogs ("file headers" for ODS2, "file records" for NTFS) storing the inode-analogs in a file ($MFT in NTFS) and <A HREF="http://www.ntfs.com/ntfs-mft.htm" TITLE="ntfs.com">allocating disk blocks for a given file in extents</a ntfs.com> (starting block number, number of contiguous blocks) rather than on a block-by-block basis as say Ext2fs or the BSD FFS. Note that nothing keeps FFS code or Ext2fs code from allocating a file's disk blocks contiguously, just that the on-disk structures don't require it. NTFS and ODS2 store a file's disk blocks as extents.
More to the point: non-log-structured filesystems that allocated a file's disk blocks in extents have always seemed to require defragmenting for some reason. Back in the day, Raxco and Executive software sold defragmenter software for VMS. SGI's Irix used to use a filesystem called "EFS" that resembled FFS but allocated in extents rather than block-by-block. SGI shipped Irix with a defragmenter and a root crontab entry that ran it weekly (as I recall). I've never had a clear idea of why extent-based filesystems require this, but perhaps it's an analog of malloc algorithms like buddy system or first fit that end up leaving a lot of unallocatable "holes" in the heap.
The <A HREF="http://www.winntmag.com/Articles/Index.cfm?IssueID=20&ArticleID=304" TITLE="winntmag.com">history of NTFS defragmenters</a winntmag.com> seems a bit questionable as well. Microsoft clearly threw a bone to Executive Software - allowing them to basically write the native API defragmenting calls, which gave Diskeeper a big leg up on any potential competitors. This is the uncompetitive behavior that should (but never does) get MSFT in trouble.
#