Talk:File system fragmentation

From Wikipedia, the free encyclopedia

To-do list for File system fragmentation: edit · history · watch · refresh

Here are some tasks you can do:
  • Expand:
    • Explain how the efficiency of page cache/buffer cache combined with readahead decreases with fragmentation
    • In proactive techniques, add keeping related files in the same cylinder groups to improve locality of reference, as in Unix File System
    • XFS allocation groups, if they are relevant (see "Scalability in the XFS File System" source)
    • More information about retroactive techniques. Perhaps mention algorithms used in defragmentation tools?
    • http://lwn.net/Articles/81357/
    • HFS Plus from the "Mac OS X Internals: A Systems Approach"
    • Sparse files causing fragmentation
    • User space fragmentation avoidance (ref. sparse files; allocating zero-filled files
    [1])
    • Explain what might be considered a self-defragmenting filesystem (which redirects here)
Priority 6  

Contents

[edit] 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)

[edit] 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)

[edit] "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)

[edit] 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 (UTC)

[edit] 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)

[edit] 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)