Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Measuring Fragmentation in HFS+

Posted by pudge on Wed May 19, 2004 12:03 PM
from the bring-out-the-big-guns dept.
keyblob8K writes "Amit Singh takes a look at fragmentation in HFS+. The author provides numbers from his experiments on several HFS+ disks, and more interestingly he also provides the program he developed for this purpose. From his own limited testing, Apple's filesystem seems pretty solid in the fragmentation avoidance department. I gave hfsdebug a whirl on my 8-month-old iMac and the disk seems to be in good shape. I don't have much idea about ext2/3 or reiser, but I know that my NTFS disks are way more fragmented than this after similar amount of use."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • Huh? (Score:5, Insightful)

    by Anonymous Coward on Wednesday May 19 2004, @12:04PM (#9196442)
    but I know that my NTFS disks are way more fragmented than this after similar amount of use

    Is this based off of instinct, actual data, or what?
    • Re:Huh? (Score:5, Funny)

      by lpangelrob2 (721920) on Wednesday May 19 2004, @12:10PM (#9196491)
      (Last Journal: Friday February 18 2005, @03:11PM)
      Maybe he ran defrag in windows and measured how many bright blue blocks were next to the medium blue blocks and the dark blue blocks. :-)
      [ Parent ]
      • Re:Huh? by rixstep (Score:2) Wednesday May 19 2004, @08:38PM
        • Re:Huh? by linzeal (Score:1) Wednesday May 19 2004, @09:15PM
    • Re:Huh? (Score:5, Informative)

      by Ann Elk (668880) on Wednesday May 19 2004, @12:39PM (#9196728)

      My own experience, using a small tool I wrote to analyze NTFS fragmentation:

      NTFS is pretty good at avoiding fragmentation when creating new files if the size of the file is set before it is written. In other words, if the file is created, the EOF set, and then the file data is written, NTFS does a good job of finding a set of contiguous clusters for the file data.

      NTFS does a poor job of avoiding fragmentation for files written sequentially. Consider a file retrieved with wget. An empty file is created, then the contents are written sequentially as it is read from the net. Odds are, the file data will be scattered all over the disk.

      Here's a concrete example. Today, I downloaded Andrew Morton's 2.6.6-mm4.tar.bz2 patch set. (Yes, I run WinXP on my Toshiba laptop -- deal with it.) Anyway, the file is less than 2.5MB, but it is allocated in 19 separate fragments. I copied it to another file, and that file is unfragmented. Since the copy command sets EOF before writing the data, NTFS can try ot allocate a contiguous run of clusters.

      Note - This was done on uncompressed NTFS. My feeling is that compressed NTFS is even worse about fragmentation, but I don't have any numbers to back that up.

      [ Parent ]
      • Re:Huh? (Score:5, Insightful)

        (Yes, I run WinXP on my Toshiba laptop -- deal with it.)

        Why would anybody have a problem with you running Windows XP on your laptop? I'm a card-carrying Linux Zealot, and I don't have a problem with it.
        [ Parent ]
        • Re:Huh? (Score:5, Funny)

          by EvilAlien (133134) on Wednesday May 19 2004, @01:45PM (#9197332)
          (Last Journal: Tuesday June 06 2006, @08:27PM)
          "'m a card-carrying Linux Zealot, and I don't have a problem with it."

          Apparently you are actually a closet Rational Linux Advocate. I'm sure there are a few people in the drooling horde reading these comments that will have a problem with someone being foolish enough to actually choose to run Windows on anything ;)

          I run Gentoo on my laptop, but the specs on the crusty old thing are so low that my only other "choice" would be the run Windows 95, and I'd sooner eat my usb key than do that.

          [ Parent ]
          • Re:Huh? (Score:5, Interesting)

            by bogie (31020) on Wednesday May 19 2004, @02:15PM (#9197575)
            (Last Journal: Tuesday October 29 2002, @10:47AM)
            Actually the number of Windows users dwarfs the numbers of Linux users here these days. Sure Widows gets beatup on more because of the constant worms etc but have a look at the average "is linux ready for the desktop" thread. You get post after post of people critical of Linux on the desktop. At best some people will agree that linux is fine in some very specific situations. As I've said many times there is a reason why Slashdot won't show recent web browser statistics. My guess is it over 80% IE and not just because people are at work.

            For the record I also use XP on my laptop. Until everything works perfectly out of the box, ACPI and all, I'm not installing any nix on it.
            [ Parent ]
      • Re:Huh? by Rakefighter (Score:2) Wednesday May 19 2004, @03:28PM
        • Re:Huh? by Ann Elk (Score:2) Wednesday May 19 2004, @03:54PM
        • Re:Huh? by Tukla (Score:1) Thursday May 20 2004, @01:12PM
        • 2 replies beneath your current threshold.
      • Re:Huh? by robosmurf (Score:1) Thursday May 20 2004, @04:25AM
      • Re:NTFS is pretty good at avoiding fragmentation?! by orangesquid (Score:2) Wednesday May 19 2004, @03:47PM
      • Re:NTFS is pretty good at avoiding fragmentation?! by devilspgd (Score:2) Wednesday May 19 2004, @06:45PM
      • 4 replies beneath your current threshold.
    • by Calibax (151875) * on Wednesday May 19 2004, @12:41PM (#9196755)
      This is a very arcane procedure in XP. I shall try to explain, but only a professional should attempt this.

      1. Right click on drive icon, select properties
      2. Select Tools tab and click on "Defragment Now"
      3. Click on "Analyze"
      4. When analysis finishes, click on "View Report"

      This shows two list windows, one containing general properties of the disk such as volume size, free space, total fragmentation, file fragmentation and free space fragmentation. The second list shows all fragmented files and how badly they are fragmented.

      [ Parent ]
      • Re:How to determine fragmentation... (Score:5, Insightful)

        by spectecjr (31235) on Wednesday May 19 2004, @12:55PM (#9196854)
        (http://www.popcornfilms.com/)
        This is a very arcane procedure in XP. I shall try to explain, but only a professional should attempt this.

        1. Right click on drive icon, select properties
        2. Select Tools tab and click on "Defragment Now"
        3. Click on "Analyze"
        4. When analysis finishes, click on "View Report"

        This shows two list windows, one containing general properties of the disk such as volume size, free space, total fragmentation, file fragmentation and free space fragmentation. The second list shows all fragmented files and how badly they are fragmented.


        If you're not using the same tool to measure fragmentation on each OS, how do you know that they're using the same semantics to decide what a fragmented file is?

        IIRC, the Linux tools use a different metric to calculate fragmentation than the NT ones.
        [ Parent ]
        • Re:How to determine fragmentation... by twbecker (Score:1) Wednesday May 19 2004, @01:28PM
          • Re:How to determine fragmentation... (Score:5, Informative)

            by pantherace (165052) on Wednesday May 19 2004, @01:52PM (#9197389)
            Well, all modern operating systems handle it so that any program, except certain tools such as the defragmenter, which either look at it directly, or use a lower level call.

            NTFS is horrible. on a system installed less than a week ago, and a few programs (nwn, firefox, avg, itunes, aa, nvdvd, windows updates, and a couple more programs, it has 9.3GB used, and it is reported that it has "Total Fragmentation: 22%, File Fragmentation: 45%"

            So yes there are various methods of calculating file fragmentation. (2 I can think of: (# of files with fragments)/(total number of files) = 0 for a totally defragemented hd (& gives nice percentages) & (# of file fragments)/(total number of files) = 1 for a perfectly defragmented hd. or variations on those, and I haven't been able to find what calculations Windows, & e2fstools use, so I can't tell.

            [ Parent ]
          • Re:How to determine fragmentation... (Score:4, Informative)

            by spectecjr (31235) on Wednesday May 19 2004, @04:53PM (#9199332)
            (http://www.popcornfilms.com/)
            How many ways are there do define fragmented files? If I can read the file starting from the byte address of the first byte of the file sequentially all the way to the EOF, it isn't fragmented. Otherwise, every time I have to jump to a non-sequential byte address, that's another fragment. Am I missing something?

            As an example, look up the docs on ext2. Note that file fragments are not necessarily the same as fragmented files. Also note that people use the "file fragment" number as an indicator of how fragmented their ext2 partition is - which is wrong.
            [ Parent ]
      • Re:How to determine fragmentation... by hey! (Score:2) Wednesday May 19 2004, @01:16PM
      • Re:How to determine fragmentation... by megarich (Score:1) Wednesday May 19 2004, @03:19PM
      • What's a "Right Click"?????

        -Faithful Macuser
        (ok I have a 3 button logitech)
        [ Parent ]
      • Re:How to determine fragmentation... by swilver (Score:3) Wednesday May 19 2004, @09:43PM
      • Re:How to determine fragmentation... by Tim C (Score:2) Wednesday May 19 2004, @01:40PM
      • 1 reply beneath your current threshold.
    • Re:Huh? by Anonymous Coward (Score:1) Wednesday May 19 2004, @12:25PM
    • 4 replies beneath your current threshold.
  • HFS+ defrag source (Score:5, Informative)

    by revscat (35618) * on Wednesday May 19 2004, @12:06PM (#9196458)
    (Last Journal: Friday May 21 2004, @12:42PM)
    As mentioned in the article, HFS+ does defragging on the fly when files are opened if they are less than 20MB. The source code for this is available here [arstechnica.com], as is a discussion about it that contains input from some Darwin developers.
    • Re:HFS+ defrag source by dealsites (Score:2) Wednesday May 19 2004, @12:09PM
      • Re:HFS+ defrag source by Joe5678 (Score:3) Wednesday May 19 2004, @12:14PM
        • Re:HFS+ defrag source by aristotle-dude (Score:2) Wednesday May 19 2004, @12:17PM
        • Re:HFS+ defrag source by kormoc (Score:1) Wednesday May 19 2004, @12:18PM
        • Re:HFS+ defrag source (Score:5, Interesting)

          by Exitthree (646294) on Wednesday May 19 2004, @12:20PM (#9196572)
          (http://www.exitthree.com/)

          You've only defeated the purpose if you re-fragment the file again after opening it. If this isn't the case, the amortized cost (the initial cost of de-fragmentation when opening the first time minus the speed benefits from a file in a single chunk) over the many times the file is read yields a speed bonus, not a speed loss.

          A good example is me, installing a program from disk onto my computer. I run the program and it accesses a group of files that have been fragmented when copied to my hard drive. The first time it opens the files it spends a little extra time de-fragmenting them. However, subsequent times that I open the program, these files will load faster.

          [ Parent ]
      • Re:HFS+ defrag source (Score:5, Informative)

        by Daniel_Staal (609844) <DStaal@usa.net> on Wednesday May 19 2004, @01:28PM (#9197201)

        I believe the actual sequence is this:

        1. Get request for file
        2. Open File
        3. Buffer file to memory
        4. Answer request for file
        5. If needed, defragment file

        In other words, it defrangments after the file has been returned to the program needing it, as a background process. The buffer to memory is a pre-existing optimization, so the only real trade off is the background processor usage goes up. If you aren't doing major work at the time, you'll never notice. (And if you are doing major work, you probably are using files larger than 20MB in size anyway.)

        Files larger than 20MB just aren't defragmented, unless you have another tool to do it.

        [ Parent ]
    • Re:HFS+ defrag source by Unnngh! (Score:2) Wednesday May 19 2004, @12:12PM
      • Re:HFS+ defrag source (Score:4, Informative)

        by jimfrost (58153) * <jimf@frostbytes.com> on Wednesday May 19 2004, @02:47PM (#9197821)
        (http://www.frostbytes.com/~jimf)
        No, FFS does not do after-the-fact defragmentation. It attempts to allocate blocks that have low seek latency as files are extended. For the most part this avoids the problem entirely.

        If you ever wondered why there is a "soft limit" on FFS filesystems, the reason why is that its allocator's effectiveness breaks down at about the point where the filesystem is 90% full. So they sacrifice 10% of the filesystem space so that they can avoid fragmentation problems. It's not a bad tradeoff, particularly these days.

        I didn't know that HFS+ used an after-the-fact defragmentation system, but they've been around for awhile too. Significant research was done into such things as part of log-based filesystem research in the early 1990s (reference BSF LFS and Sprite). You had to have a "cleaner" process with those filesystems anyway (to pick up abandoned fragments of the log and return them to the free pool) so it made sense to have it also perform some optimization features.

        [ Parent ]
      • Re:HFS+ defrag source by bofkentucky (Score:2) Wednesday May 19 2004, @02:52PM
      • Re:HFS+ defrag source by MrChuck (Score:2) Wednesday May 19 2004, @03:34PM
    • Re:HFS+ defrag source by rharder (Score:3) Wednesday May 19 2004, @12:12PM
    • Re:HFS+ defrag source (Score:5, Interesting)

      by shotfeel (235240) on Wednesday May 19 2004, @12:17PM (#9196545)
      I thought this was a feature of Panther, not HFS+.

      HFS+ has been around since OS 8.5 (?? somewhere in OS 8). So either this is a feature of HFS+ that hasn't been implemented until now, or its a bit of code added to Panther. Or has HFS+ been updated?
      [ Parent ]
      • Re:HFS+ defrag source (Score:5, Informative)

        by ahknight (128958) * on Wednesday May 19 2004, @12:27PM (#9196624)
        (http://www.macgeekery.com/)
        As stated in the article, this is a feature of the HFS+ code in Panther. The filesystem cannot have a defrag feature as the filesystem is just a specification. The implementation of that specification, however, can do most anything to it. :)
        [ Parent ]
        • Re:HFS+ defrag source by Entropy2016 (Score:1) Wednesday May 19 2004, @02:59PM
        • Re:HFS+ defrag source (Score:5, Insightful)

          by ahknight (128958) * on Wednesday May 19 2004, @01:08PM (#9196946)
          (http://www.macgeekery.com/)
          Last time I checked filesystems were also operatining system components. Often these components might be referred to as drivers.

          Then you didn't check hard. Again, HFS+ is a specification of how to write data to media in order to organize another collection of data. The implementation is what handles the defragging. There are no drivers involved as drivers are the software component of a hardware/software union and there is no hardware involved at this level (just logical organization).
          [ Parent ]
        • Re:HFS+ defrag source (Score:4, Informative)

          by Anonymous Coward on Wednesday May 19 2004, @01:23PM (#9197131)
          You just made his point. The DRIVER does the defragging. The HFS+ is a specification for how the files are laid out and written to the disk, such that a driver that understands this specification can read it. Linux has HFS+ drivers, but I doubt they defrag on the fly. Supposedly (though I don't know), Mac OS versions prior to 10.3 didn't defrag either.

          So therefore it might be a part of the operating system's filesystem. That's the system that deals with files. But that's not what was asked. What was asked was whether it was an inherent feature of HFS+, and that's not possible, since HFS+ doesn't tell the OS what to do when a file is opened, only how the stuff is stored on the disk.

          Perhaps you didn't understand the dual nature of the word filesystem: it can be the subsystem of the OS that handles files, or it can be the physical representation of the data on to the hard drive. If you assume it's only the first, your explanation makes sense. If you assume the second one (which would be the usage intended and understood by most people given the fact that the question and response were about HFS+ (physical filesystem) compared to Panther (OS filesystem)), then you'd be wrong.

          And I've been trolled, but who cares.
          [ Parent ]
        • 1 reply beneath your current threshold.
      • Re:HFS+ defrag source by solios (Score:3) Wednesday May 19 2004, @02:14PM
        • Re:HFS+ defrag source by ahknight (Score:2) Wednesday May 19 2004, @03:05PM
        • Re:HFS+ defrag source (Score:5, Informative)

          by shamino0 (551710) on Wednesday May 19 2004, @03:18PM (#9198203)
          (Last Journal: Thursday March 25 2004, @06:59PM)
          HFS+ was one of the major features of the OS 8.1 update. OS 8.0 and earlier can't "see" HFS+ volumes- they see a tiny disk with a simpletext file titled "where have all my files gone?" which, if I remember correctly, gives a brief explanation that the disk is HFS+ and requires 8.1 or higher to view. :)

          And the person who came up with this idea was a genius. This is far far better than what most other operating systems do (refuse to mount the volume.)

          If I boot MS-DOS on a machine that has FAT-32 or NTFS volumes, I simply don't find any volume. I can't tell the difference between an unsupported file system and an unformatted partition. If the file system would create a FAT-compatible read-only stub (like HFS+ does), it would be much better for the user. Instead of thinking you have a corrupt drive, you'd know that there is a file system that your OS can't read.

          [ Parent ]
      • Re:HFS+ defrag source by VirtualWolf (Score:1) Wednesday May 19 2004, @07:37PM
      • Re:HFS+ defrag source by Swedentom (Score:1) Thursday May 20 2004, @04:51AM
    • Re:HFS+ defrag source by DrEldarion (Score:1) Wednesday May 19 2004, @12:55PM
    • Re:HFS+ defrag source by TheNetAvenger (Score:2) Wednesday May 19 2004, @05:16PM
    • Re:HFS+ defrag source by meme_police (Score:1) Wednesday May 19 2004, @01:01PM
    • Re:HFS+ defrag source by Mitz Pettel (Score:1) Wednesday May 19 2004, @01:01PM
    • Re:HFS+ defrag source (Score:5, Insightful)

      by MattHaffner (101554) on Wednesday May 19 2004, @01:04PM (#9196925)
      Are you talking about the "Optimizing System" phase? As far as I know, that updates binary-library prebindings--not fragmentation. You can read more about it here:

      http://developer.apple.com/documentation/Perform an ce/Conceptual/LaunchTime/Tasks/Prebinding.html

      In theory, when you install anything (on any system) and have a reasonable amount of contiguous free space on your disk, the installed files should always be unfragmented since I believe that's what most file systems look for first to allocate: a large chunk of contiguous space.

      Fragmentation typically occurs more when you open a file, increase its size, and write it back out. But operations that write large files to disk that do not know beforehand what the final size may also do this to some files that were only written once to your disk. For example, some of the largest fragmented files on my HFS+ volume are things snagged with BitTorrent. The fragments in these files are very regular chunks of blocks, which could be the typical 'buffer' size BT grabs when writing.
      [ Parent ]
    • Re:Offtopic by revscat (Score:2) Wednesday May 19 2004, @04:38PM
      • Re:Offtopic by toupsie (Score:2) Wednesday May 19 2004, @07:51PM
      • Re:Offtopic by bnenning (Score:3) Wednesday May 19 2004, @08:06PM
        • Re:Offtopic by amRadioHed (Score:3) Wednesday May 19 2004, @09:12PM
          • Re:Offtopic by toupsie (Score:3) Thursday May 20 2004, @12:02AM
        • Re:Offtopic by Sj0 (Score:2) Thursday May 20 2004, @07:34AM
        • Re:Offtopic by revscat (Score:2) Thursday May 20 2004, @08:31AM
      • 1 reply beneath your current threshold.
    • Re:Offtopic by Sj0 (Score:2) Wednesday May 19 2004, @05:15PM
    • Re:Offtopic by Goo.cc (Score:1) Wednesday May 19 2004, @05:58PM
      • 1 reply beneath your current threshold.
    • 2 replies beneath your current threshold.
  • File allocation Table (Score:4, Interesting)

    by SirChris (676927) on Wednesday May 19 2004, @12:06PM (#9196463)
    (Last Journal: Wednesday July 16 2003, @04:29PM)
    what type of file system is there where there is no main allocation table just a header then the file then a header then the file so you could theoretically break a disk and still read the half that was good because all pertinent information relating to a file was in one place?
    • Re:File allocation Table by jdunn14 (Score:2) Wednesday May 19 2004, @12:36PM
    • Re:File allocation Table by marcus (Score:1) Wednesday May 19 2004, @12:57PM
    • Re:File allocation Table (Score:5, Insightful)

      by SideshowBob (82333) on Wednesday May 19 2004, @01:05PM (#9196928)
      That isn't a filesystem that is a tape. Any number of tape systems exist, pick whichever one you like.
      [ Parent ]
    • Re:File allocation Table by johannesg (Score:2) Wednesday May 19 2004, @01:11PM
    • There are a couple things that you have to consider. For one, if part of the disk corrupts, how will you identify a header? Or for that matter, how would you identify the header space vs. file space in a non-corrupted file system?

      You're probably thinking "just store the size of the file", This is perfectly valid, but it does have certain implications. You see, in Comp-Sci, we refer to a list like this as a "linked list". The concept basically being that each item in the list has information (i.e. a "link") that helps identify the next item in the list. Such a data structure has a worst case access time of O(n). Or in other words, if your item is at the end of the list,and you have you have 2000 files, you'll have to check through all two thousand headers before finding your file.

      Popular file systems circumvent this by using what's called a Tree structure. A tree is similar to a linked list, but allows for multiple links that point to children of the node. A node that has no children is referred to as a "leaf node". In a file system the directories and files are nodes of a tree, with files being leaf nodes. This configuration gives us two performance characteristics that we must calculate for:

      1. The maximum number of children in a node.
      2. The maximum depth of the tree.

      Let's call them "c" for children and "d" for depth. Our performance formula is now O(c*d) and is irrespective of the number of items in the data structure. Let's make up and example to run this calculation against:

      Path: /usr/local/bin/mybinary

      Nodes:
      / (34) /usr (10) /usr/local (9) /usr/local/bin (72)

      Longest path: /usr/X11R6/include/X11

      Plugging the above numbers (72 for c, 4 for d) we get a worst case of 72*4 = 288 operations. Thus our worst case is much better than the linked list. And if we calculate the real case to access /usr/local/bin/mybinary, we get 34+10+9+72 = 134 operations.

      Hope this helps. :-)

      [ Parent ]
    • Re:File allocation Table by Elwood P Dowd (Score:2) Wednesday May 19 2004, @01:40PM
    • 3 replies beneath your current threshold.
  • Measuring fragmentation in NTFS (Score:2, Informative)

    by Anonymous Coward on Wednesday May 19 2004, @12:08PM (#9196478)
    Goto My Computer. Right click the drive to be analyzed. Select tools/defragment now.../Analyze.

    This was my PhD Thesis.
    • Re:Measuring fragmentation in NTFS by strictnein (Score:2) Wednesday May 19 2004, @12:15PM
      • Re:Measuring fragmentation in NTFS (Score:5, Interesting)

        by moonbender (547943) <(moc.liamg) (ta) (rednebnoom)> on Wednesday May 19 2004, @12:29PM (#9196648)
        I wrote a script some time ago to more easily let me check how badly my partitions are fragmented, here's it's current output:
        C: 5,72 GB Total, 1,97 GB (34%) Free, 4% Fragmented (8% file fragmentation)
        D: 40,00 GB Total, 1,00 GB (2%) Free, 41% Fragmented (82% file fragmentation)
        E: 66,69 GB Total, 105 MB (0%) Free, 10% Fragmented (21% file fragmentation)
        F: 30,00 GB Total, 1,21 GB (4%) Free, 3% Fragmented (7% file fragmentation)
        G: 10,00 GB Total, 1,54 GB (15%) Free, 5% Fragmented (9% file fragmentation)
        H: 35,03 GB Total, 551 MB (1%) Free, 39% Fragmented (79% file fragmentation)

        D ("Dump") and H ("Online") get a lot of throughput, by personal computing standards anyway, E ("Games") doesn't get changed that much, but if it does, a lot of data leaves and comes. Seems like whenever I defrag D or H, they're back to the values above within days. I guess Win XP has a hard time doing the internal on-the-fly defragging of the hard drives that rarely have moer than 1% free space... Guess I should just get a new HD and have some more free space that way - but I bet I'd have that filled up with junk after some weeks, anyway.

        That said, I'm not sure how relevant this is for NTFS partitions, anyway. I recall hearing that they aren't affected by fragmentation as much as FAT partitions (which were a nightmare), however I'm not sure if that means they don't fragment that easily (heh) or whether accessing data isn't slowed down as much by any existing fragmentation.

        I've also rarely heard anyone talking about fragmentation in the popular Linux file systems, a Unix partisan I know actually thought they didn't fragment full stop, which I don't believe is possible, at least not if you consider situations which might not occur in practice. But then again, I suppose Linux might solve it the same way Apple seems to - I guess I'll know more after a couple of hundred comments on this article. :)
        [ Parent ]
      • 1 reply beneath your current threshold.
    • 1 reply beneath your current threshold.
  • NTFS is not so bad (Score:5, Interesting)

    by W2k (540424) <wilhelm,svenselius&gmail,com> on Wednesday May 19 2004, @12:11PM (#9196498)
    (http://www.ws83.net/ | Last Journal: Monday May 14 2007, @03:38AM)
    It must be pretty damn good if it can outdo NTFS. I have three computers with WinXP (NTFS 5.1) that I run quite a bit of data through on a daily basis, and neither needs to be defragmented very often at all (two of them have never needed defragmentation in more than a year of use). Mind you, I might fall into some special category of people who don't fall victim to fragmentation for some reason. Anyway, my point is, before you make remarks regarding how well this compares to NTFS, and/or how much "Microsoft sucks", consider how well NTFS still holds up considering its age. Another bonus is, I don't risk losing file system integrity if there's a power failure. ;)
  • HFS Filesystem vs. ReiserFS (Score:2, Interesting)

    I've had a continued problem on my iBook for the past year or so.

    Under HFS+ in Mac OS X Jaguar or Panther, after about a day of having a clean install, fresh partition and format my hard drive starts making clunking noises and the system locks up (without actually freezing) -- then when reboot attempts are made they take aeons.

    Under ReiserFS in Gentoo Linux for PPC: never have the problem. Same hard drive. Months of use, never once hear the hard drive being funky. No lockups.

    Do I put the blame on HFS? OS X? I just can't figure out this strange problem.
  • My stats (Score:5, Informative)

    by Twirlip of the Mists (615030) <twirlipofthemists@yahoo.com> on Wednesday May 19 2004, @12:13PM (#9196509)
    I throw these out there for no real reason but the common interest.

    I've got a G4 with an 80 GB root drive which I use all day, every day. Well, almost. It's never had anything done to it, filesystem-maintenance-wise, since I last did an OS upgrade last fall, about eight months ago.
    Out of 319507 non-zero data forks total, 317386 (99.34 %) have no fragmentation.
    Not too shabby, methinks.
    • Re:My stats by Anonymous Coward (Score:1) Wednesday May 19 2004, @12:33PM
    • Re:My stats by haxor.dk (Score:2) Wednesday May 19 2004, @07:07PM
    • 1 reply beneath your current threshold.
  • by freelunch (258011) on Wednesday May 19 2004, @12:15PM (#9196521)
    I Never really had a problem under Linux until I started using P2P..

    I know that Reiser does extremely well with space management on small files (CDDB database is a great example). Do any of the other Linux FSs do better than EXT2 with frag?
  • by Chuck Bucket (142633) on Wednesday May 19 2004, @12:21PM (#9196583)
    (http://pitchforkmedia.com/ | Last Journal: Tuesday March 23 2004, @09:08PM)
    it's not how fragmented your disk is, it's what you can do with your fragmented disk that counts.

    CVB
  • Panther Defrag (Score:5, Interesting)

    by stang7423 (601640) on Wednesday May 19 2004, @12:23PM (#9196597)
    I'm sure someone else will point this out as well but its worth noting. In 10.3 there is kernel level defragmentation. When a file is accessed the kernel checks to see if its fragmented, then moves it to a area of the disk where it can exist unfragmented. I think there is a limitation to file size under 20MB but it may be higher. This still gets rid of a great deal of fragmenation. Just food for thought.
  • HPFS (Score:3, Interesting)

    by gmuslera (3436) <gmuslera@@@gmail...com> on Wednesday May 19 2004, @12:23PM (#9196599)
    (Last Journal: Tuesday April 12 2005, @11:12PM)
    When i had OS/2, i enjoyed the low hpfs fragmentation. When you copy a file it gives to it the next free block that fit in that size, as long you have a big enough free chunk of the disk, the file were not fragmentated. But also it unfragmented when more operations where done with the directory or the file system. I remember that a basic "unfragment" script was to go thru all directories and just copy or even rename the files to unfragment them.

    But not sure how this are managed in linux filesystems, not just ext2/3 and reiserfs, but also in xfs and jfs.

  • by spankalee (598232) on Wednesday May 19 2004, @12:24PM (#9196602)
    aiee, here's my output:

    btreeReadNode(105): diff = 2048, this should *NEVER* have happened!
    initSpecialFile(202): failed to retrieve extents for the Catalog file.
    hfsdebug: failed to access the Catalog File.

    I can't find any info about this on the site. Is anyone else getting this error?

  • ReiserFS and fragmentation (Score:2, Interesting)

    by chrysalis (50680) on Wednesday May 19 2004, @12:24PM (#9196607)
    (http://00f.net/)
    Recent 2.6-mm kernels contains Chris Mason's work in order to dramatically reduce the fragmentation of ReiserFS filesystems.

    It's really good on filesystems with a lot of files or on databases.

  • by greymond (539980) on Wednesday May 19 2004, @12:25PM (#9196610)
    (http://www.morbidgames.com/ | Last Journal: Tuesday November 30 2004, @07:38PM)
    Seriously, with NTFS and HFS+ I see very little fragmentation on both my Wintel and Apple machines.

    Both have 40gig HD's and both have applications installed/uninstalled quite often. My PC feels the worst of this as he gets games installed and uninstalled in addition to the apps.

    For example the last time I reinstalled either of these machines was back in january(new year fresh install) and since then my pc has felt the install/uninstal of various games usually ranging from 2-5 gigs each. The Apple has been installed and with the exception of updates, plugins, video codecs and basic small apps that get added/upgraded often has done alright.

    Right now Norton System Works on my PC is saying the drive is 4% fragmented. Disk Warrior on my Apple is saying the drive is 2% fragmented.

    Conclusion: Fragmentation is no longer an issue for the HOME USER(note how i'm not saying your companies network doesn't need to be concerned), unless there still running a FAT32 partition >. which well they deserve to have there computer explode at that point anyway.
  • Other FSs (Score:1)

    Has anyone got a similar prog to measure fragmentation for reiserfs, ext2/ext3, and NTFS? And, what the heck, FAT32 as well? Could be very useful...
    • Re:Other FSs by chrwei (Score:1) Wednesday May 19 2004, @03:01PM
  • Centrifugal Force (Score:5, Funny)

    by Prince Vegeta SSJ4 (718736) on Wednesday May 19 2004, @12:29PM (#9196647)
    I just put my hard drive in my drier when it is fragmented. Since the group of unfragmented bits weighs more than the fragmented ones, The spinning action causes all of those stray bits to attach to the greater mass.