Content deleted Content added
Jim Grisham (talk | contribs) →Types: Added sub-section on fragmentation of file system data structures |
GreenC bot (talk | contribs) Rescued 1 archive link; reformat 1 link. Wayback Medic 2.5 |
||
Line 76:
If the final size of a file subject to modification is known, storage for the entire file may be preallocated. For example, the [[Microsoft Windows]] [[swap file]] (page file) can be resized dynamically under normal operation, and therefore can become highly fragmented. This can be prevented by specifying a page file with the same minimum and maximum sizes, effectively preallocating the entire file.
[[BitTorrent (protocol)|BitTorrent]] and other [[peer-to-peer]] [[filesharing]] applications limit fragmentation by preallocating the full space needed for a file when initiating [[download]]s.<ref>{{cite journal |date=29 March 2009 |first=Jeffrey |last=Layton |title=From ext3 to ext4: An Interview with Theodore Ts'o |journal=[[Linux Magazine]] |publisher=[[QuinStreet]] |url=http://www.linux-mag.com/id/7272/ |archive-url=https://web.archive.org/web/20090401152937/http://www.linux-mag.com/id/7272 |url-status=usurped |archive-date=April 1, 2009 }}</ref>
A relatively recent technique is [[delayed allocation]] in [[XFS]], [[HFS+]]<ref>{{cite web |first=Amit |last=Singh |date=May 2004 |title=Fragmentation in HFS Plus Volumes |work=Mac OS X Internals |url=http://osxbook.com/software/hfsdebug/fragmentation.html |access-date=2009-10-27 |archive-date=2012-11-18 |archive-url=https://web.archive.org/web/20121118173110/http://osxbook.com/software/hfsdebug/fragmentation.html |url-status=dead }}</ref> and [[ZFS]]; the same technique is also called allocate-on-flush in [[reiser4]] and [[ext4]]. When the file system is being written to, file system blocks are reserved, but the locations of specific files are not laid down yet. Later, when the file system is forced to flush changes as a result of memory pressure or a transaction commit, the allocator will have much better knowledge of the files' characteristics. Most file systems with this approach try to flush files in a single directory contiguously. Assuming that multiple reads from a single directory are common, locality of reference is improved.<ref name=xfs-scalability>{{cite conference |first=Adam |last=Sweeney |first2=Doug |last2=Doucette |first3=Wei |last3=Hu |first4=Curtis |last4=Anderson |first5=Mike |last5=Nishimoto |first6=Geoff |last6=Peck |date=January 1996 |title=Scalability in the XFS File System |publisher=[[Silicon Graphics]] |book-title=Proceedings of the USENIX 1996 Annual Technical Conference |___location=[[San Diego, California]] |url=http://www.soe.ucsc.edu/~sbrandt/290S/xfs.pdf |access-date=2006-12-14 }}</ref> Reiser4 also orders the layout of files according to the directory [[hash table]], so that when files are being accessed in the natural file system order (as dictated by [[readdir]]), they are always read sequentially.<ref name=reiser4-google>{{cite web |first=Hans |last=Reiser |date=2006-02-06 |title=The Reiser4 Filesystem |url=http://video.google.com/videoplay?docid=6866770590245111825&q=reiser4 |work=Google TechTalks |access-date=2006-12-14 |archive-url=https://web.archive.org/web/20110519215817/http://video.google.com/videoplay?docid=6866770590245111825&q=reiser4 |archive-date=19 May 2011 |url-status=dead }}</ref>
| |||