Talk:File system fragmentation

message: Consider copy on write filesystems, which use immutable allocated blocks (like ZFS)
This allocation will just waste time, and will not change the characteristics of the filesystem  —Preceding unsigned comment added by 129.65.102.1 (talk) 17:49, 27 February 2008 (UTC)
thread_title: Bittorrent, etc. preallocation does not always prevent fragmentation

message: Wasn't there an attempt at a file system that attempted to avoid that by writing data in layers, from top to bottom, letting the old data drop? Could someone tell me its name please? Thanks! 84.129.170.44 (talk)  —Preceding undated comment added 04:23, 5 April 2009 (UTC)
thread_title:  Specific File System 

message: For the record, I created this article as I was dissatisfied with the current defragmentation article that:
# Approaches the problem from the inverse perspective, talking about how to solve the problem without saying what exactly the problem is.
# Uses imprecise terminology, occasionally saying "partition" instead of "file system", etc.
# Includes the misconception that fragmentation only takes place on the level of individual files.
# Spreads the common myth of Unix file systems not needing defragmentation, citing only unreliable sources (the majority of "reliable" research on file systems does indicate that fragmentation is a problem, and I will cite sources as necessary)
I have attempted to mitigate these somewhat, but ultimately decided to write this article. I don't know if I can get it into a good enough shape to be merged with "defragmentation" (if at all), but I will try, and I will cite genuine research in the progress. It may or may not be considered a "rewrite" at this point. Any criticisms and comments are very welcome. -- intgr 03:53, 14 December 2006 (UTC)
thread_title: Reasons for duplicating "[[defragmentation]]" article

message: While I myself added this to the article, I'm not sure it is fair to consider "related file fragmentation" a type of fragmentation. While research dealing with fragmentation very often also touches the topic of keeping related files together (e.g, files in a single directory), I don't think I can recall any instances where it's actually referred to as "fragmentation" per se.
However, consider when an archive is unpacked. As all files are decompressed in order, they will likely be laid out sequentially. But when time goes on, and files are added and deleted, the directory tree in which the files were decompressed into, becomes less and less "contiguous", e.g., can be considered "fragmented". -- intgr 14:21, 19 December 2006 (UTC)
replies: text: http://www.kernelthread.com/mac/apme/fragmentation/ talks about this as "User-level data fragmentation" -- intgr 10:40, 21 December 2006 (UTC)
thread_title: "Related file fragmentation"?

message: As the article has been tagged with , does anyone have ideas how to do that (e.g., what to merge, what not to merge, and what to throw away)? -- intgr 14:32, 30 January 2007 (UTC)
thread_title:  Merge with [[defragmentation]] 

message: Although it would seem logical to merge the "Defragmentation" and the "File system fragmentation" articles, the first will naturally focus on practical aspects of dealing with the problem, and the second on a more theoretical understanding of the root cause of the problem.  Combined into one article, there is a danger that it will get overly complex -- or that important material will be deleted to keep the article simple.--69.87.193.53 19:22, 18 February 2007 (UTC)
thread_title:  Don't Merge 

message: A much better method, only merges the needless copy of File system fragmentation#Cause.
Spitfire (talk) 01:35, 25 September 2008 (UTC)
thread_title:  Merge [[Defragmentation#Causes of fragmentation]] with File system fragmentation 

message: There is POSIX fallocate API for allocating predermined size for file (or part of it). It have two motivations: make sure there is enaugh free space for file (so write operations will not file becuase of no space), and file can be preallocated on single extent on disk if possible in optimal manner.
Some tools already uses it to decress fratgmentation.  —Preceding unsigned comment added by 149.156.67.102 (talk) 21:50, 7 December 2009 (UTC)
thread_title:  posix_fallocate 

message: Although the phrase goes back 10 years to the initial article,
What does fragmentation have to do with "allow in-place modification" mentioned in the very beginning of the article?
DGerman (talk) 01:12, 29 November 2016 (UTC)
thread_title:  Allow in-place modification  

message: Hello fellow Wikipedians,
I have just modified 2 external links on File system fragmentation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20041117233607/http://www.eecs.harvard.edu/vino/fs-perf/papers/keith_a_smith_thesis.pdf to http://www.eecs.harvard.edu/vino/fs-perf/papers/keith_a_smith_thesis.pdf
*Added archive https://web.archive.org/web/20110519215817/http://video.google.com/videoplay?docid=6866770590245111825&q=reiser4 to http://video.google.com/videoplay?docid=6866770590245111825&q=reiser4
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 16:31, 30 September 2017 (UTC)
thread_title:  External links modified