Talk:File system fragmentation

Bittorrent, etc. preallocation does not always prevent fragmentation

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)

Specific File System

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).

Reasons for duplicating "defragmentation" article

For the record, I created this article as I was dissatisfied with the current defragmentation article that:

1. Approaches the problem from the inverse perspective, talking about how to solve the problem without saying what exactly the problem is.
2. Uses imprecise terminology, occasionally saying "partition" instead of "file system", etc.
3. Includes the misconception that fragmentation only takes place on the level of individual files.
4. 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)

"Related file fragmentation"?

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)

http://www.kernelthread.com/mac/apme/fragmentation/ talks about this as "User-level data fragmentation" -- intgr 10:40, 21 December 2006 (UTC)

Mac OS X

I struck the Mac OS X note, since it isn't what actually happens. Mac OS X/HFS+ do not defrag at idle. What happens is that when a fragmented file is opened, it is defragged (unless the system has been up less than some specific time, and I forget what that time is). Thus, there's no "at idle" about it. Now if there's a seperate "at idle" process, by all means put the claim back in (but please reference it). Thanks. :) --Steven Fisher 18:58, 19 December 2006 (UTC)

Thanks for correcting, I should have looked it up before mentioning; I've heard this myth from several people and it turns out not to be true indeed. :) -- intgr 19:32, 19 December 2006

Merge with defragmentation

As the article has been tagged with {{merge|Defragmentation}}, 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)

Don't Merge

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)

I totally disagree...defragging is the way by which the natural order is kept...extra work that users have to do is good for their character. —The preceding unsigned comment was added by 68.249.171.240 (talk)

• Don't merge. I agree with 69.87.193.53. File system fragmentation is an issue for OS/filesystem designers, while defragmentation is an issue for system administrators. They are as different as Dirt and Cleaning. --N Shar (talk • contribs) 04:18, 13 March 2007 (UTC)

I also disagree, merging the two articles would lead to one gigantic overly complex article. As stated earlier, information would probably be cut for the sake of simplicity, resulting in an incomplete article overall. Just link from the fragmentation article to the defragmentation article. --Rollerskatejamms 13:07, 13 March 2007 (UTC)

Merge Defragmentation#Causes of fragmentation with File system fragmentation

A much better method, only merges the needless copy of File system fragmentation#Cause.

Spitfire (talk) 01:35, 25 September 2008 (UTC)

posix_fallocate

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)