Mac OS X 10.3 Defrags Automatically

← Back to Stories (view on slashdot.org)

Mac OS X 10.3 Defrags Automatically

Posted by pudge on Thursday October 30, 2003 @11:21AM from the hot-character-adaptive-respawning dept.

EverLurking writes "There is a very interesting discussion over at Ars' Mac Forum about how Mac OS X 10.3 has implemented an on-the-fly defragmentation scheme for files on the hard drive. Apparently it uses a method known as 'Hot-File-Adaptive-Clustering' to consolidate fragmented files that are under 20 MB in size as they are accessed. Source code from the Davwin 7.0 Kernel is cited as proof that this is happening."

181 comments

Min score:

Reason:

Sort:

Yes But ... by k3vmo · 2003-10-30 11:25 · Score: 0, Offtopic

Can it open a beer for me?
1. Re: Yes But ... by Anonymous Coward · 2003-10-30 11:58 · Score: 1, Funny
  
  Surpisingly, yes, it can. If you look at line 94 character 7, you can see the comment where it says it can.
Amortized cost... by Ianoo · 2003-10-30 11:25 · Score: 3, Interesting

Obviously doing this process slows down file access a little. I wonder whether any safeguards are in place, such as turning the system off after a certain I/O load is reached? If not, this may not be such a good idea.

Also, I wonder whether if you were to calculate the extra time (perhaps 500ms) to defragment each fragmented 20MB file against doing a manual defrag every month, and whether it's actually worth it...

Don't some Linux filesystems already do this to some extent? I could be hallucinating again, but I'm sure I read this somewhere.
1. Re:Amortized cost... by anarkhos · 2003-10-30 11:30 · Score: 1
  
  The process could be delayed until the disk isn't being used. The file would still use twice as many blocks but with today's hard drives that shouldn't be a problem.
  
  As for Linux filesystems they don't support FileIDs so who cares |-)
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
2. Re:Amortized cost... by Ianoo · 2003-10-30 11:31 · Score: 1
  
  OK, so I was only partially hallucinating. Searching Google reveals that most Linux filesystems don't usually need to be defragmented simply because they're better designed. I don't quite understand the reasons, however. Anyone have information?
3. Re:Amortized cost... by viniosity · 2003-10-30 11:49 · Score: 1
  
  Drives are defragged to allow the OS to access the files faster. If there is a speed hit it would one time- overall there would be an increase in file access speeds. I mean, it's not like a hard disk journal where there are safeguards that make taking a speed hit worth it. In this case, defrag is all about access speed.
4. Re:Amortized cost... by jrstewart · 2003-10-30 11:58 · Score: 4, Informative
  
  I can only speak for ext2/ext3. Linux tries to preallocate large blocks when writing files to prevent fragmentation. If you disk is mostly full (or even was once mostly full) or you have heavy concurrent disk activity going on you can still get fragmentation.
  
  The end goal of the disk subsystem is to get your data to you as soon as you need it. In general that goal would be achieved if the data you want to read next happened to be under the read head. If you're reading sequentially through a single file then this will happen when the file is in a single contiguous region (i.e. unfragmented). For any other access pattern fragmentation doesn't matter as much, since you'll be skipping around the disk regardless of how the files are arranged.
  
  Prefetching heuristics and caching can hide a lot of these problems from the user as well.
5. Re:Amortized cost... by Steve+Cowan · 2003-10-30 11:59 · Score: 2, Interesting
  
  Yes it would be a one-time hit, but we hard disk intensive audio and video people don't want to be streaming multiple tracks off our hard disks while they are defragging themselves!
  
  Self-defragging might be great on file servers but Macs are (largely) about the multimedia.
6. Re:Amortized cost... by JonoPlop · 2003-10-30 12:21 · Score: 2, Informative
  
  Yes it would be a one-time hit, but we hard disk intensive audio and video people don't want to be streaming multiple tracks off our hard disks while they are defragging themselves!
  
  ...which is why there's the 20 MB limit.
7. Re:Amortized cost... by clifyt · 2003-10-30 12:26 · Score: 5, Interesting
  
  "Drives are defragged to allow the OS to access the files faster."
  
  Are you so sure?
  
  I have talked with a senior OS designer (one of the non-free ones) and his view is that these days, defragging does more damage than it saves.
  
  Why? Drives generally have large caches on them and multiple platters / read heads.
  
  Noting this, the fastest way to get data off a drive might not be a straight line. Its looks pretty when you run the different utilities and makes the home makers of whom believe everything should be put away neat and tidy, but the engineer had mentioned that being defragged means you loose a lot of advantages of those multiple readheads and cache. He claimed that it was actually better to leave your drive to its own devices, allowing for about 30% free space at all times, and you will see a speedup over a defragged drive.
  
  I didn't believe it at first, but his arguments did make a lot of sense even though it went against everything I had learned before. He actually mentioned if he had his choice, he'd make certain defraggers would NEVER work, but the market believes that these are necessary so its easier to have these things included as well as supporting third parties, so its there.
8. Re:Amortized cost... by bdsesq · 2003-10-30 13:42 · Score: 5, Insightful
  
  Noting this, the fastest way to get data off a drive might not be a straight line.
  
  This is true. However it is also true that a defrag does not have to put the data in physically contigious blocks. It can just as easily put the data in whatever configuration makes retrevial work fastest on that particular drive geometry.
  
  This means that an intelligent defrag can improve performance.
9. Re:Amortized cost... by MikeXpop · 2003-10-30 14:00 · Score: 1, Troll
  
  No kidding it slows down!
  
  I don't want to start a holy war here, but what is the deal with you Hot-File-Adaptive-Clustering fanatics? I've been sitting here at my freelance gig in front of a Panther machine (OS 10.3) for about 22 minutes now while it attempts to defrag a 20 Meg file on my hard drive. 22 minutes. At home, on my B&W G3 running Jaguar, which by all standards should be a lot slower than Panther, the same operation would take about 2 minutes. If that.
  
  In addition, during this defrag, 17 MB files will not copy. And everything else has ground to a halt. Even Expose is straining to keep up as I type this.
  
  I won't bore you with the laundry list of other problems that I've encountered while working with auto-defrag on, but suffice it to say there have been many, not the least of which is I've never seen a Panther machine that has run faster than other apples, despite the OS's advancements. System 7 runs faster than Panther at times. From a productivity standpoint, I don't get how people can claim that Panther is a "superior" OS.
  
  Panther addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to upgrade to Panther over other faster, cheaper, more stable OS's.
  
  --
  Etiquette is etiquette. He kills his mother but he can't wear grey trousers.
10. Re:Amortized cost... by Hes+Nikke · 2003-10-30 15:17 · Score: 1
  
  gah! it's a semi-ontopic troll - even if all the "facts" are still as wrong as ever
  
  --
  Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
11. Re:Amortized cost... by dheeraj · 2003-10-30 15:18 · Score: 1
  
  What is WRONG with you, mods? This is a parody of a classic troll used in every Mac-related story on here. +1 Funny, goddammit. I'd certainly do it if I could.
  
  --
  --- Why yes, I am the webmaster of Microsuck.com
12. Re:Amortized cost... by Anonymous Coward · 2003-10-30 16:13 · Score: 0
  
  This means that an intelligent defrag can improve performance.
  
  An improvement measured in milliseconds per month.
  
  Pass.
  
  If the OS wants to rearrange the blocks on my disk automatically, in the background, yippie skippy. But you won't see me giving two shits about one way or the other.
13. Re:Amortized cost... by dasunt · 2003-10-30 18:22 · Score: 1
  
  I thought (but could be wrong) that hard drives internally split up the platters for speed games - sort of an internal 'raid 0' approach.
  
  It would make sense - modern hard drives already lie about their geometry. If a drive has 2 platters/4 heads, by doing an internal 'raid 0', that drive is now four times faster then the competition.
  
  Perhaps a slashdotter with a bit of hard drive clue could tell us if that's the case.
14. Re:Amortized cost... by Trillan · 2003-10-30 22:53 · Score: 1
  
  Definitely. I'm embarassed that it took me so long to recognize it. :)
15. Re:Amortized cost... by ploiku · 2003-10-31 05:31 · Score: 2, Informative
  
  Nope:
  
  Link
16. Re:Amortized cost... by ploiku · 2003-10-31 05:36 · Score: 1
  
  Drives do have large caches, but the data needs to be moved from the drive to the cache at some point. And keep in mind that you're talking about an 2 - 8MB cache for a 100GB+ drive in many cases.
  
  "Multiple readheads" isn't a huge advantage, I think. The multiple readheads are 1 per platter, and are all on the same armature - they can't move around independantly.
  
  Given that Apple isn't marketing this (it started with people looking at the kernel source), I'd guess that they did actual performance measurements and found an improvement.
17. Re:Amortized cost... by stripes · 2003-10-31 05:48 · Score: 1
  
  For any other access pattern fragmentation doesn't matter as much, since you'll be skipping around the disk regardless of how the files are arranged.
  
  For an extent based FS a less fragmented file is more likely to have whatever part of it's extent table is needed in memory to do a read or write on it. (for a block mapped one that is a non issue because the block map takes space proportional to the file size, not the number of fragments)
18. Re:Amortized cost... by Horny+Smurf · 2003-10-31 06:49 · Score: 1
  
  When a linux/open source tool doesn't exist, the zealots usually claim it isn't needed, up until someone finally gets fucked over by the shortcoming, and writes a tool. Then the zealots claim the open source/linux version is superior.
  
  lather, rinse, wash, repeat.
  
  VMS (and Windows NT I think) allows you to specify an expected file length when creating a file. The posix creat call is far simpler.
  
  Fragmentation *is* a problem under all linux fs. It's not as much of an issue as would be with a desktop OS since there may be a few thousand open files being read/written at any given time for a web server, mail server, etc. The anticipatory io scheduler sorts them out so it makes no difference in the end.
19. Re:Amortized cost... by realdpk · 2003-10-31 07:37 · Score: 1
  
  Indeed. I have large backup servers, one of which is Linux, the others FreeBSD. Fragmentation is a problem because the files get very, very large - sometimes larger than any single drive in the arrays.
  
  One time I saw something like 60% fragmentation. I'd never seen anything above 2 prior to that. :-)
20. Re:Amortized cost... by MikeXpop · 2003-10-31 09:01 · Score: 1
  
  Heh, you aparently don't read a lot of the articles lately. This troll has been parodied more than any other troll that I've seen in my 1.5 years of reading /. I just saw a 20 meg file was in the description, and one of the first comments was about it going slow. I can't resist a good troll.
  
  --
  Etiquette is etiquette. He kills his mother but he can't wear grey trousers.
21. Re:Amortized cost... by MikeXpop · 2003-10-31 09:05 · Score: 1
  
  Thanks for the support. I forget who, but someone had a sig that says "One man's -1 Flamebait is another man's +5 Funny". Too true.
  
  --
  Etiquette is etiquette. He kills his mother but he can't wear grey trousers.
22. Re:Amortized cost... by lone_marauder · 2003-11-05 03:18 · Score: 1
  
  Good post, but it really depends on what you are using the drive for. A file server, being used by many users to store tiny little files, is very poorly served by defragging for exactly the reasons you describe. As the file size increases and user/application population decreases, however, having data in contiguous blocks (accounting for interleave, etc.) becomes more and more advantageous.
  
  --
  who are those slashdot people? they swept over like Mongol-Tartars.
Cool but... by anarkhos · 2003-10-30 11:27 · Score: 0

I'd still like to defragment larger files even if it's done manually. Plus Optimizer requires a reboot.

--
>80 column hard wrapped e-mail is not a sign of intelligent
>life
Hmm... by Ianoo · 2003-10-30 11:28 · Score: 0, Offtopic

I also wonder how well Ars OpenForum will hold up to a Slashdotting. They run Infopop Opentopic which is Java backed by Oracle on clusters, so I'd imagine pretty darned well. Then again, it's still dynamic content with a bigass XSL (XML to HTML) transform on the top before it reaches the browser...
1. Re:Hmm... by Caesar · 2003-10-30 11:58 · Score: 1, Troll
  
  It'll survive, but I'm not sure I will when the next bill comes ;)
2. Re:Hmm... by MacJedi · 2003-10-30 13:57 · Score: 1
  
  Hail Caesar!
  
  --
  2^5
3. Re:Hmm... by Anonymous Coward · 2003-10-30 15:09 · Score: 0
  
  Man, what kind of asshole would mod down the guy who runs one of the best tech sites for a simple comment like that.
4. Re:Hmm... by Anonymous Coward · 2003-10-31 02:52 · Score: 0
  
  Because he is a giant dork.
In other news.... by m0rph3us0 · 2003-10-30 11:34 · Score: 0, Interesting

Darwin is welcomed to 1980's filesystem technology. But instead of defraging FFS just makes better decisions as to where to put files. This also explains why the hard drive on my iBook seems alot hotter since upgrading. Seriously, if Apple got rid of HFS, none of this technology would be necessary.
1. Re:In other news.... by anarkhos · 2003-10-30 11:45 · Score: 2, Interesting
  
  If Apple got rid of HFS+ they would need to replace it with something else. No other filesystem supports FileIDs for example.
  
  Time for HFS++
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
2. Re:In other news.... by squiggleslash · 2003-10-30 12:13 · Score: 3, Interesting
  
  Er, when you install OS X, you can choose UFS instead of HFS/HFS+. Then you get an old fashioned Unix-style file system. Unfortunately, doing so means that you lose metadata, forks, etc (though the Finder does a sort-of half-arsed job and creates little dot files all over the place to try to at least cover some of the metadata.)
  Me, I'd take the comparatively modern HFS+. I'm still confused as to why metadata isn't being taken seriously by the rest of the computing world.
  
  --
  You are not alone. This is not normal. None of this is normal.
3. Re:In other news.... by molo · 2003-10-30 12:20 · Score: 1
  
  No other filesystem supports FileIDs for example.
  
  How are FileIDs different than inodes then?
  
  -molo
  
  --
  Using your sig line to advertise for friends is lame.
4. Re:In other news.... by /dev/trash · 2003-10-30 12:31 · Score: 1
  
  What about ReiserFS?
5. Re:In other news.... by bill_mcgonigle · 2003-10-30 12:42 · Score: 4, Informative
  
  But instead of defraging FFS just makes better decisions as to where to put files....Seriously, if Apple got rid of HFS, none of this technology would be necessary.
  
  You speak as though HFS+ has trouble with file fragmention. It's easily already one of the best filesystems for avoiding fragmentation - I've worked on Macs that have been run for years without attention and were better than 90% unfragmented. This is considerably better than any of the Microsoft filesystems, for instance. This tweak is an improvement, to get from 90% to 99%.
  
  HFS+ doesn't just put the files down randomly, either, it has some smarts.
  
  This also explains why the hard drive on my iBook seems alot hotter since upgrading.
  
  The only way this feature can do that is if you're writing small files continuously. That's very strange software behavior, and perhaps a worst case for this optimizer. Why would you be doing that?
  
  Don't get me wrong, HFS+ isn't the best filesystem ever created, but it's very featureful (multiple forks, file ID's, case-preserving, case-insensitive-possible, UNICODE, attributes, 64-bit file sizes, POSIX compliance, etc.) and the MacOS relies on it heavily. Anything to replace it would be a superset of HFS+. Fortunately, Apple hired the guy behind the Be Filesystem a few years back. I doubt he's working on iMovie 3.1.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
6. Re:In other news.... by Electrum · 2003-10-30 13:03 · Score: 1
  
  POSIX compliance
  
  Doesn't being case insensitive violate POSIX? Or has that been fixed?
7. Re:In other news.... by anarkhos · 2003-10-30 13:10 · Score: 4, Informative
  
  If you refer to a file by an inode you are basically creating a hard link so if the file is deleted the file still 'exists'.
  
  Also you cannot get a file path from an inode thus if the file path is changed (moving a file for example) the application cannot know what the new path is.
  
  A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
  
  Also FileIDs are smaller so searching for files using a FolderID or FileID is faster and uses less memory.
  
  They're not equivalent.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
8. Re:In other news.... by anarkhos · 2003-10-30 13:22 · Score: 1
  
  UFS on MacOS X is also very slow and your Aliases will break when the original file is moved or renamed.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
9. Re:In other news.... by anarkhos · 2003-10-30 13:24 · Score: 1
  
  1) Yes it does, break it
  
  2) Fuck POSIX |-)
  
  I'll take usability over some standard which is easy to work-around.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
10. Re:In other news.... by anarkhos · 2003-10-30 13:27 · Score: 1
  
  BFS also lacks many of these things, most notably FileIDs.
  
  I hope he's working on HFS++ instead of some BFS port.
  
  BTW filename extensions still suck...what was Apple thinking?
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
11. Re:In other news.... by Muggins+the+Mad · 2003-10-30 13:38 · Score: 1
  
  >> This also explains why the hard drive on my iBook seems alot hotter since upgrading.
  > The only way this feature can do that is if you're writing small files continuously. That's very strange software behavior, and perhaps a worst case for this optimizer. Why would you be doing that?
  Sounds like compiling to me. Typical usage for a developer.
  - Muggins the Mad
12. Re:In other news.... by babbage · 2003-10-30 14:17 · Score: 1
  
  Actually, I usually hear HFS+ described as case insensitive while reading, but case invariant or case preserving while writing. That is, the filesystem will record the file however it was first written, but can permit case insenstive searching.
  That way, when working in the BSD shell, everything works the same way it does on any other POSIX shell, with case sensitivity being the norm, but when working in the Finder you can browse & search in a case insensitive way.
  There's a pretty good case to be made that this is the right way for a filesystem to go -- it kind of adheres to the rule of thumb that systems should be generous in what they accept (broad definitions of acceptable input, etc) but strict in what they produce (narrow definitions of what will be returned).
  
  --
  DO NOT LEAVE IT IS NOT REAL
13. Re:In other news.... by Teese · 2003-10-30 14:20 · Score: 5, Informative
  
  Its a just recently added feature!
  
  See the -s option for newfs_hfs:
  
  (from man newfs_hfs)
  
  -s
  
  Creates a case-sensitive HFS Plus filesystem. By default a case-insensitive filesystem is created. Case-sensitive HFS Plus file systems require a Mac OS X version of 10.3 (Darwin 7.0) or later
  
  --
  "I'm a Genius!"*
  
  *Not an actual Genius
14. Re:In other news.... by jonadab · 2003-10-30 14:41 · Score: 1
  
  > I'm still confused as to why metadata isn't being taken seriously by the
  > rest of the computing world.
  
  The rest of the world does take metadata seriously; we just don't store it
  the same way as the Mac does. What do you suppose email headers are, if not
  metadata? The thing is, different kinds of data have different kinds of
  associated metadata, so it's not a foregone conclusion that storing the
  metadata at the filesystem level is necessarily the only good way to do
  things. Making it a part of the file format in many cases makes a large
  amount of sense. OpenOffice files, for example, contain very significant
  amounts of metadata -- not just formatting, but things like the author of
  the document, when it was last edited, and so forth.
  
  However, if you want to see a filesystem that goes hog-wild with storing
  metadata at the filesystem level, you should try out the BeOS, where (for
  example) your address book is just a folder containing a bunch of zero-byte
  files.
  
  --
  Cut that out, or I will ship you to Norilsk in a box.
15. Re:In other news.... by jonadab · 2003-10-30 14:48 · Score: 1
  
  > The only way this feature can do that is if you're writing small
  > files continuously. That's very strange software behavior
  
  Err, what? Writing small files is more than 99% of the writing that a typical
  filesystem does, and many applications cause them to be written fairly well
  continuously. Just three examples off the top of my head of applications that
  normally result in this behavior include email, usenet, web browsing (disk
  cache). Two of these are *extremely* common desktop end-user applications.
  
  Any filesystem that has problems continouously writing small files is junk.
  
  --
  Cut that out, or I will ship you to Norilsk in a box.
16. Re:In other news.... by Hes+Nikke · 2003-10-30 15:29 · Score: 2, Informative
  
  POSIX compliance
  
  Doesn't being case insensitive violate POSIX? Or has that been fixed?
  
  yes
  
  --
  Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
17. Re:In other news.... by squiggleslash · 2003-10-30 15:45 · Score: 1
  
  The rest of the world does take metadata seriously; we just don't store it the same way as the Mac does. What do you suppose email headers are, if not metadata?
  I'm talking about FILE metadata. Good grief! Why the hell would I be talking about other types of metadata in a discussion about file systems?
  
  --
  You are not alone. This is not normal. None of this is normal.
18. Re:In other news.... by anarkhos · 2003-10-30 15:49 · Score: 1
  
  NOOOOOooooooooo....
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
19. Re:In other news.... by Guy+Harris · 2003-10-30 16:14 · Score: 1
  
  That way, when working in the BSD shell, everything works the same way it does on any other POSIX shell
  
  Nope:
  % uname -sr Darwin 7.0.0 % echo "Hi, mom!" >Foo % cat foo Hi, mom! % echo "Bye, dad!" >FoO % cat fOo Bye, dad! % cat foo Bye, dad!
  
  It's always case-insensitive (unless you've constructed a case-sensitive HFS+) - there's no BSD shell vs. Finder difference.
20. Re:In other news.... by drsmithy · 2003-10-30 16:19 · Score: 2, Informative
  
  Me, I'd take the comparatively modern HFS+. I'm still confused as to why metadata isn't being taken seriously by the rest of the computing world.
  Because the rest of the computing world is more interested in successfully interacting with itself and has realised that filesystem metadata is practically impossible to successfully move between systems using "common" tools.
  Apple has finally figured this out, too, which is why they're moving away from it.
  Filesystem metadata is another one of those cool ideas that is (or, rather, was) kneecapped because of lowest-common-denominator restrictions.
21. Re:In other news.... by babbage · 2003-10-30 16:25 · Score: 1
  
  I stand corrected, and I should have thought of this.
  This is exactly the problem when installing the LWP library for Perl -- it offers to install /usr/bin/HEAD for you, as a tool for doing http-head requests on web servers. On most POSIX filesystems this isn't a big deal, but on HFS+ it ends up clobbering /usr/bin/head, the standard tool for retrieving the opening lines from a file or data stream (a/k/a file). The LWP maintainers don't see this as a bug on their end, because they get the behavior they want on every other platform -- hence three years after OSX came out and it's still an issue for some people. (Maybe Apple should just add LWP to their default Perl and the problem would go away for newbies...).
  Thanks for the correction. :-)
  
  --
  DO NOT LEAVE IT IS NOT REAL
22. Re:In other news.... by drsmithy · 2003-10-30 16:32 · Score: 2, Funny
  
  BTW filename extensions still suck...what was Apple thinking?
  Interoperability.
23. Re:In other news.... by Random832 · 2003-10-30 17:16 · Score: 1
  
  shouldn't the opening lines util be called /bin/head, not /usr/bin/head? in which case the worst this does is render HEAD inaccessible
  
  --
  We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
24. Re:In other news.... by Wordsmith · 2003-10-30 18:01 · Score: 1
  
  I hate when I can't get head
25. Re:In other news.... by jbolden · 2003-10-30 18:02 · Score: 1
  
  IMHO because its sort of a 1/2 and 1/2 solution. With a mainframe you get a full database filesystem: "datafiles" don't exist in the Unix sense and data is owned by applications. The effect is very powerful as you intermediate forms of data don't exist and applications can engage in very complex behaviors towards data.
  
  Conversely on Unix you get the "everything is a file" and "a file is a stream of ASCII text" which is really powerful for shell programming but makes end user cross application interaction complicated.
  
  Metadata is sort of 1/2 way in between. Datafiles have other associated data which sort of connects them to applications which may or may not be intererpreted the same way by other applications which may or may not respect the metadata and you can't search or organize based on this metadata.
26. Re:In other news.... by Anonymous Coward · 2003-10-30 20:13 · Score: 0
  
  In other words, FileIDs allow your OS to avoid being a hard-coded, non-user-friendly hunk of crap like Windows and Unix.
  
  Had Microsoft implemetned FileIDs, you'd rarely hear anyone bitching about the registry.
27. Re:In other news.... by bill_mcgonigle · 2003-10-31 02:11 · Score: 1
  
  Just three examples off the top of my head of applications that normally result in this behavior include email, usenet, web browsing (disk cache).
  
  Perhaps for a server, but not for workstation. If I'm browsing the web, it's going to be at least 10 seconds between cache writes, as the page loads and I read it. Email or usenet would be similar - a bulk write every five minutes or so, maybe an occasional write on message send. That's not 'continuously' for a filesystem or a hard drive - that's light duty in so far as affecting its thermal properties.
  
  If we're talking about a high-volume mail or news server, I can see your point, but we expect server disks to run hot anyhow.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
28. Re:In other news.... by squiggleslash · 2003-10-31 03:08 · Score: 1
  Actually no, that's why things like "resource forks" are being dropped.
  Having metadata in the file system doesn't mean you can't interact with other platforms. It does mean that you lose the metadata when you move a file from one place to another - however:
  
  The icon used to represent a file does not have to move from one computer to another
  
  The position of that icon within the window that shows it does not have to move from one computer to another
  
  The application used to open the file does not have to move from one computer to another
  
  The file type does need to move from one computer to another - but that is the only metadata that currently is transfered from one machine to another, albeit regularly via file extentions
  
  Metadata is metadata. It's not the data, so it rarely needs to actually move from one system to another. For the specific cases where it does, we usually have mechanisms for transfering that data. There's no reason to forget about the other cases, and the fact we continue to do so means that computers continue to be less forgiving, less intelligent, and less user friendly than they could be.
  --
  You are not alone. This is not normal. None of this is normal.
29. Re:In other news.... by Anonymous Coward · 2003-10-31 03:11 · Score: 0
  
  > shouldn't the opening lines util be called /bin/head, not /usr/bin/head?
  > in which case the worst this does is render HEAD inaccessible
  
  Don't be silly, it's still accessible typing /usr/bin/head.
30. Re:In other news.... by squiggleslash · 2003-10-31 03:13 · Score: 1
  
  You're confusing metadata with... er, something else. Actually I'm not sure, but it sounds like you're thinking I'm refering to the ability to have the filesystem manage databases and stuff.
  Metadata is information about a file. Most file systems include a limited about of it - actually, most restrict it to the filename and maybe some very limited type information (Unix, for instance, stores whether it's a file or directory or pipe, etc.) We often overload the filename with type information to get around the lack of an actual file-type field stored with files.
  Metadata isn't a half-and-half solution. You add it to a filesystem and you have something you didn't have to begin with. It adds capabilities that didn't exist and doesn't remove a thing. Microsoft, however, doesn't do metadata, and unfortunately most of the people working on the big Desktop replacement projects for Unix/Linux have got it into their heads that whatever MS does is the way to do it.
  Even the frickin' Amiga had metadata and had a solution for storing it on a file system that doesn't support such things. It was ugly (you had a ".info" file for every ordinary file) but it worked. It's a shame that the lack of competition and alternatives has meant that people have forgotten what's necessary.
  
  --
  You are not alone. This is not normal. None of this is normal.
31. Re:In other news.... by babbage · 2003-10-31 03:26 · Score: 1
  
  You'd probably have to take that up with Apple, but I suspect that the tool is seen as a userland one rather than a system level one, hence /usr/bin instead of just /bin. I've just checked on two Solaris machines (`uname -r` one gives 5.7, the other gives 5.8) and one Linux machine (RedHat 6.2), and all three of them have their head utility at /usr/bin/head -- so it's not just OSX that puts head in with the userland toolkit in /usr/bin.
  I think the fix you're grasping for is to put LWP's HEAD in something like /usr/local/bin or /opt/bin with the rest of the manually installed programs that are not part of the default distribution. Aside from the $PATH issue that you hint at, this should be a portable, non-destructive solution to the problem.
  The only complication I can think of is that the local/manual bin/ dir tends to be in different places on different systems -- OSX doesn't ship with an /opt tree, for example, but most Solaris systems do. The Fink project for Unix software on OSX likes to use /sw, but this is non-standard, and manually putting stuff in there could interfere with packages managed by Fink itself. I think that /usr/local is nearly universal across distributions & versions & SysV vs. BSD lineages, but I've heard some people complain about it, so I'm sure that some systems at least won't even have that.
  Writing LWP in such a way that it can sniff out & use the correct local installation directory may seem to be more trouble than it's worth to correct a problem that, to date, is only apparent on systems running on top of the HFS+ filesystem. There's a case to be made for "fixing" LWP to be more portable, but the counter-argument to that -- which has been winning since 1999 or so, when people first started trying to install LWP on their OSX Public Beta machines in fairly large numbers -- has been "you Mac guys are the only ones complaining, maybe the problem is on your end." And so we end up with a stalemate.
  *shrug*
  
  --
  DO NOT LEAVE IT IS NOT REAL
32. Re:In other news.... by ploiku · 2003-10-31 05:40 · Score: 1
  
  >I'm still confused as to why metadata isn't being taken seriously by the rest of the computing world.
  
  It isn't being taken seriously by much of the UNIX world.
  
  Microsoft is actively heading in that direction WinFS is essentially an integrated database of arbitrary indexed attributes related to file data. Even NTFS supports arbitrary numbers of forks in a file, which is a step up from HFS/+ 's 2 fork system.
33. Re:In other news.... by shamino0 · 2003-10-31 07:16 · Score: 1
  
  If you refer to a file by an inode you are basically creating a hard link ... A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
  I think you're musunderstanding something.
  A FileID is a persistent handle that refers to a file. It is only valid for a single disk volume. If a file is moved to a different volume, the ID changes.
  In every respect that matters, it's functionally equivalent to an inode number.
  The real question here is why nobody has made a UNIX API to open a file using a volume-ID of some kind (which may have to be defined) and the inode number. Using an API like this, UNIX apps could get the same functionality as Mac apps. Moving a filename around the directory tree would not affect a program's ability to open it.
  Creating a hard link to the inode is unnecessary for an API like this. After all, the standard open() call already does all the requred work. It already has to convert a pathname into a volume/inode index as a part of its normal behavior.
34. Re:In other news.... by stripes · 2003-10-31 07:16 · Score: 1
  
  There are some Unixes that let you open a file give it's i-number (er, and device number, or a path to the devices FS, I forget which). There are also some Unix-ish OSes (Plan9!) that let you get a part for any open file.
  If you had those two primitaves would not FileIDs and i-numbers be the same? Or is there more to a FileID?
  A FileID is really more equivalent to a path, or rather used in place of a path with the advantage that the path can change and the fileID remains the same. Thus referring to a FileID is less fragile.
  
  Maybe. It is also why if I take CoolApp and rename it to CoolApp.old and install the new CoolApp in the same place as the old one all manner of stuff still runs CoolApp.old! I assume it will also sometimes be unable to find a file if I end up moving someting ontop of the old one (unless things that keep FileIDs keep both the FileID and a path to the file in case the FileID goes stale...which may be the case because I don't recall this happining, unlike the CoolApp.old bit)
35. Re:In other news.... by shamino0 · 2003-10-31 07:27 · Score: 1
  
  ... Microsoft, however, doesn't do metadata ...
  Microsoft's file systems do as much metadata as UNIX does. On FAT (and I think FAT32) every file a timestamp and a set of attribute bits (directory, read-only, hidden, system and archive). On NTFS, each file gains two more timestamps (so you have create, modify and access) and security attributs.
  Of course, neither Windows nor UNIX supports all the metadata that MacOS does - file type, file creator, icon position, user comments, memory partition sizes (for classic apps), etc.
36. Re:In other news.... by shamino0 · 2003-10-31 07:31 · Score: 1
  
  Microsoft is actively heading in that direction WinFS is essentially an integrated database of arbitrary indexed attributes related to file data. Even NTFS supports arbitrary numbers of forks in a file, which is a step up from HFS/+ 's 2 fork system.
  HFS+ actually supports an arbitrary number of forks, even though there are only standard definitions for the resource and data forks.
  Not too long ago, it was common to find anti-Mac zealots routinely criticize Apple for having a resource fork. They had a wide variety of disparaging remarks to make against the concept. I wonder if these same people will maintain that attibude when Microsoft starts providing the same thing. Somehow, I don't think they will.
37. Re:In other news.... by squiggleslash · 2003-10-31 07:31 · Score: 1
  
  I know, I know, by Microsoft doesn't do metadata I meant "Above the bare minimum that everyone else does."
  Truth be told, I don't even think HFS+ does enough metadata, but it does some above datestamps and filenames, and that's a big improvement over the others.
  BeFS would be the way to go.
  
  --
  You are not alone. This is not normal. None of this is normal.
38. Re:In other news.... by stripes · 2003-10-31 07:33 · Score: 1
  
  Sounds like compiling to me. Typical usage for a developer.
  
  I don't think so. The source code files are generaly written in their entirety by the editor even if you only make changes starting halfway though a file (or add a few functions on the end). So they will normally only occupy one extent (i.e. be unfragmented), and are stunningly unlikely to have mroe then 7 extents (needed for auto-defrag to kick in). The object files are again only written in their entierty. The .s files (if written) are the same.
  I think there is seaking around when you write the executable out, but only to fill in the jump addresses, and they are overwrites not appends. Unlikely to be much fragmentation there.
  The systme include files and lib files ought not be fragmented, but if they this would fix that the first time you use each such file, and since they are all unfragmented next time through you won't have a problem there (it might even eventually save you some time).
  I don't think a developer will run into this much (if at all!) during compiling.
39. Re:In other news.... by shamino0 · 2003-10-31 07:50 · Score: 1
  
  NOOOOOooooooooo....
  YEEEEEeeeeeeess....
  You have the option of formatting your drive as case sensitive, if you really want to.
  Personally, I'd recommend against it, unless you have a really good reason to choose otherwise. Most Mac apps assume case insensitivity. For instance Dantz has this knowledgebase article regarding Panther and Retrospect. Note the paragraph which reads:
  Case-Sensitive HFS+ (Panther Server only)
  * Panther Server's Disk Utility allows administrators to format disks with a new case-sensitive HFS Plus file system. Retrospect 5.1 does not recognize case-sensitive file names. If "file" and "FILE" exist in the same directory, only one will be backed up.
  
  Interestingly, they say that this feature is only available on the server edition. Can anyone confirm or disprove this?
40. Re:In other news.... by bandy · 2003-10-31 11:46 · Score: 1
  
  It is and has been taken seriously - it's called "the registry" by our pals up in Redmond.
  
  --
  "You might as well get your son a ticket to hell as give him a five string banjo." -unknown minister
41. Re:In other news.... by ahunter · 2003-10-31 13:30 · Score: 1
  
  My experience with HFS+ is that it suffers very badly from directory fragmentation. DiskWarrior should be supplied as standard with all macs; on 10.2, directory fragmentation can become a problem in months on a well-used system, and it reduces the reliability of HFS+ to the point that it can cause kernel panics. (Which are random, and make you think you have a RAM or a processor problem). Plus it makes filesystem performance really, really suck - you start to find that some operations can be hundreds of times slower than they should be.
  
  Apple's fsck is useless: it can detect these sort of problems, but can't fix them. Norton Utilities can't either, sometimes (orphan files seem to fox it, in particular). Can't remember the specific message that fsck gives, but you'll know it if you see it (it implies a problem was fixed that wasn't. I suspect there's a /* IMPLEMENT ME */ comment in the source somewhere near there).
  
  DiskWarrior reported that the disk was about 30% out of order; running it found about 20 files that nothing else could, solved the kernel panic problem, and made a huge difference to speed (things that would take minutes suddenly were instantaneous). It shouldn't have been necessary, though.
42. Re:In other news.... by anarkhos · 2003-10-31 18:59 · Score: 1
  
  You dont' move a file to another volume, you copy a file to another volume. Sheesh
  
  And it is NOT an inode! And before you even say it, it isn't a file descriptor either.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
43. Re:In other news.... by jbolden · 2003-10-31 23:35 · Score: 1
  
  I understand what metadata is. The purpose of metadata is to attach additional information to application specific data. A database filesystem plus datafiles being application specific goes much further in that direction. That's what I meant by 1/2 and 1/2. You are getting 1/2 of what the mainframe package gets you.
  
  A good example is a versioning system (version 1, version 2...) gets you 1/2 of what CVS gets you (versioning and branching).
44. Re:In other news.... by jonadab · 2003-11-01 02:31 · Score: 1
  
  > If I'm browsing the web, it's going to be at least 10 seconds between
  > cache writes, as the page loads and I read it.
  
  Surf with images disabled, do you?
  
  > Email or usenet would be similar - a bulk write every five minutes or so
  
  You apparently get a lot less email than I do. When I check my mail, it
  writes files every second for several minutes.
  
  --
  Cut that out, or I will ship you to Norilsk in a box.
45. Re:In other news.... by jonadab · 2003-11-01 02:47 · Score: 1
  
  > I'm talking about FILE metadata.
  
  Yes, but my point is, metadata is metadata. The difference between storing it
  as part of the file and storing it as part of a thingydoo attached to the file
  is a difference of paradigm, not of substance. The BeOS would store info about
  when a file was last printed in the filesystem metadata for the file; OO.o
  would store it in the metadata XML, not in the content portion of the file,
  but it would be part of the file as far as the filesystem is concerned. To
  the user, the approaches are equivalent (except that one is independent of the
  filesystem and therefore makes sense for a cross-platform application; the
  other is so highly platform-specific that no cross-platform app can use it,
  which makes it effectively redundant except for single-platform apps, which
  are hopefully a dying breed at this point).
  
  There are some things it makes sense to store as metadata at the filesystem
  level. Mainly, things that apply to all files on the system, not just certain
  types of files. So, content-type, for example. (The BeOS stores the MIME
  content-type as filesystem-level metadata; DOS and Windows store a file
  extension that is essentially equivalent, albeit somewhat inferior. The Mac
  has its type and creator codes, which also are essentially equivalent albeit
  somewhat inferior.) Permissions are another example. (FAT filesystems lack
  here, but the other major ones are pretty decent. Especially with the
  introduction of ACLs.)
  
  But things that only make sense for certain types of files (e.g., icons,
  which only make sense for applications, generally, or From headers, which
  only makes sense for internet messages, or phone numbers, which only make
  sense for address book entries) can be stored in a manner specific to that
  type of file, without loss of generality (since there was no generality in
  the first place).
  
  --
  Cut that out, or I will ship you to Norilsk in a box.
46. Re:In other news.... by Ahaldra · 2003-11-02 03:42 · Score: 1
  
  Interestingly, they say that this feature is only available on the server edition. Can anyone confirm or disprove this?
  "Panther Server's Disk Utility..." - you already answered your own question ;-) Panther Servers disk utility gives you that option in the graphical interface, whereas panther' disk utility doesn't. it is available on both, but on regular 10.3 you need to enable it via command line tools as your parent poster pointed out. (or make Disk Utility believe it runs on pather server)
  
  --
  Code is Speech. No to Censorship.
47. Re:In other news.... by shamino0 · 2003-11-04 06:49 · Score: 1
  
  Panther Servers disk utility gives you that option in the graphical interface, whereas panther' disk utility doesn't. it is available on both, but on regular 10.3 you need to enable it via command line tools
  Thanks. I haven't yet upgraded to Panther, so my information is all second-hand, and some of what I've read has turned out to be wrong.
48. Re:In other news.... by shotfeel · 2003-11-04 09:01 · Score: 1
  
  But now Apple has depricated Resource Forks in favor of bundles. Bundles are essentially just folders and each "fork" is a separate file in the folder. That way it it can reside on pretty much any file system.
  
  See for more info.
49. Re:In other news.... by Anonymous Coward · 2003-11-04 23:29 · Score: 0
  
  The only way this feature can do that is if you're writing small files continuously. That's very strange software behavior, and perhaps a worst case for this optimizer. Why would you be doing that?
  
  Hey, can I help it if I like to store my porn in jpeg2000 to make sure it all fits on my puny 20 gig disk?
50. Re:In other news.... by drunkenbatman · 2003-11-12 10:20 · Score: 1
  
  This also explains why the hard drive on my iBook seems alot hotter since upgrading.
  
  The only way this feature can do that is if you're writing small files continuously. That's very strange software behavior, and perhaps a worst case for this optimizer. Why would you be doing that?
  
  Hmm. OSX itself writes lots of small files continuously in general, in general, don't most *nix's?
51. Re:In other news.... by bill_mcgonigle · 2003-11-13 04:26 · Score: 1
  
  OSX itself writes lots of small files continuously in general, in general, don't most *nix's?
  
  What makes you think that? Have you ever had a powerbook put its disk to sleep? The OS is still running (and not writing lots of small files continuously).
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
52. Re:In other news.... by drunkenbatman · 2003-11-13 10:21 · Score: 1
  
  What makes you think that? Have you ever had a powerbook put its disk to sleep?
  
  Well, I meant when you're actually DOING something. You can put your powerbook to sleep, but can't actually do a whole lot without it spinning up. IE, having users login... logs don't write themselves (/var/log), paging in/out memory... *nix's like fast disks.
but but by falcon5768 · 2003-10-30 11:38 · Score: 3, Funny

I want to see all the pretty colors of blocks moving themselves!!!!!!
ahh shucks.

--
"Slashdot, where telling the truth is overrated but lying is insightful."
1. Re:but but by cous_2000 · 2003-10-31 04:24 · Score: 1
  
  Don't worry.. Windows 98 is still around.. :) :-p
  
  --
  Please send comments to Helen Wait
2. Re:but but by falcon5768 · 2003-10-31 04:28 · Score: 1
  
  ahhh yes I feel better already....
  hmmm maybe I should break out my old 386, defrag on that was always nice and pretty..... and looooooooong
  
  --
  "Slashdot, where telling the truth is overrated but lying is insightful."
I think it's... by Jeremiah+Cornelius · 2003-10-30 11:56 · Score: 1

I think it's a battery-saving feature for the new PowerBooks...

--
"Flyin' in just a sweet place,
Never been known to fail..."
1. Re:I think it's... by babbage · 2003-10-31 03:57 · Score: 1
  
  How do you figure, out of curiosity? Wouldn't these occasional defragmentation operations tend to counteract the power saving option that puts the drive to sleep as much as possible? Or do you assume that wouldn't be an issue because the defrags only happen when you're using the drive anyway? Even if that's the case, this is still causing more disc activity than would happen ordinarily, so I can't see how there would be a net gain as far as power saving for the battery goes...
  
  --
  DO NOT LEAVE IT IS NOT REAL
2. Re:I think it's... by Jeremiah+Cornelius · 2003-10-31 04:15 · Score: 2, Funny
  
  ...was meant as humor! Obviously increasing background disk activity is gonna suck juice outta yer battery like a Whitehouse intern...
  
  --
  "Flyin' in just a sweet place,
  Never been known to fail..."
3. Re:I think it's... by babbage · 2003-10-31 04:53 · Score: 1
  
  Ahhh.... :-)
  /me readjusts his sarcasm detector
  
  --
  DO NOT LEAVE IT IS NOT REAL
4. Re:I think it's... by coolgeek · 2003-10-31 07:06 · Score: 2, Insightful
  
  Perhaps reading the source will reveal some insight for you all as it has for me. The defrag takes place on an hfs_open call, thus the disk, if not spinning at the time, will be powered on shortly. It also is NOT a background operation, and only applies to files that are being opened.
  I believe the rationale is that it takes little more than the same number of IOs to defrag as it is going to take to read the file once, and will take less IOs on subsequent accesses to the file (after defrag), which would appear to be imminent because the file has just been opened.
  
  --
  
  cat /dev/null >sig
Necessarily Useless by Thargok · 2003-10-30 12:05 · Score: 1

GREAT, if one ever had to defrag with HFS+
1. Re:Necessarily Useless by EdMack · 2003-10-30 12:10 · Score: 1
  
  Sorry, I don't quite get your point.. HFS+ does get fragmented, you can see this with the Norton tools.
  
  --
  puts ("Python r0cks\n");
2. Re:Necessarily Useless by Thargok · 2003-10-30 12:17 · Score: 1
  
  Yes, but the filesystem is set up well-enough that it really doesn't matter. There are still people running 7100/80s on the original HD with OS 8, and not noticing any speed difference. HDs are fast enough today that fragmentation was a problem of the past.
3. Re:Necessarily Useless by Dan+Ost · 2003-10-30 12:33 · Score: 2, Insightful
  
  Umm, isn't the HD the bottleneck of modern systems?
  
  Isn't the reason all these high performance machines have so much RAM so that
  they don't have to take the enormous hit of swapping to disk?
  
  Even ram is too slow. That's why they're putting so much cache on the chips now.
  
  --
  
  *sigh* back to work...
4. Re:Necessarily Useless by berniecase · 2003-10-30 16:25 · Score: 3, Interesting
  
  Fragmentation is a very real problem for people who need lots of contiguous free space, especially those working with multitrack audio and video files. They can't have drive heads searching around a drive for free blocks of space when they could be writing linearly.
  
  Even with this file defragmenter built-in, a drive defragmenter is still needed for certain types of users.
5. Re:Necessarily Useless by Thargok · 2003-10-30 19:07 · Score: 1
  
  Those working with multitrack audio and video files are usually working with multiple HDs anyways. And if they are serious, on a fragmented SCSI Raid. The effectiveness of defragging to is minimal as we are not not limited to 8 megs of RAM, low RPM HDs and a 25 mhz bus. Benchmarks will show you that. Defragging will also only help if you have enough HD space to actually defrag in the first place (the general rule of thumb is 15% of the HD free)
6. Re:Necessarily Useless by berniecase · 2003-10-31 01:49 · Score: 1
  
  Being serious and having the cash to plunk down for multi-drive arrays are two separate things. Having one large, fast drive defragmented is often times enough for a hobbyist, or less-than-wealthy artist working out of a home studio.
Risky decision by Apple by Amiga+Lover · 2003-10-30 12:28 · Score: 1

I'm in two minds about this. One, it's a potentially good thing to keep a filesystem constantly running well, but Secondly, I've never had one single process kill more partitions in the last ten years of using computers than when I was defragmenting them. That's my biggest concern.

If I were to get a Mac I'd hope a feature like this could be turned OFF permanently. I'm not one for just using a machine and spontaneously having an unreadable drive.
Autodefrag. (snort) by speechpoet · 2003-10-30 12:34 · Score: 5, Funny

In my day, we'd crack open the drive on our Mac SE30s, sharpen a magnet on a whetstone, and defrag that sucker by hand.

Kids these days. It's the MTV, ya know - makes 'em lazy.
1. Re:Autodefrag. (snort) by Anonymous Coward · 2003-10-30 16:42 · Score: 0
  
  I'm sorry, but I find this overused joke to be lame and boring
2. Re:Autodefrag. (snort) by zangdesign · 2003-10-30 16:56 · Score: 1
  
  You had a HARD DRIVE? I guess you were one of the lucky ones - some of us just had two floppy drives!
  
  --
  To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
3. Re:Autodefrag. (snort) by cpt+kangarooski · 2003-10-30 17:06 · Score: 1
  
  TWO floppy drives. You were lucky. Some people only had one, and had to constantly swap the disks around.
  
  But not me. I couldn't afford a floppy drive, so I had to use 400kB casette tapes instead.
  
  --
  -- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
4. Re:Autodefrag. (snort) by Anonymous Coward · 2003-10-30 20:07 · Score: 0
  
  And I only had an abacus, stone tablets, blah blah. Let's kill this zombie joke right here.
5. Re:Autodefrag. (snort) by jolshefsky · 2003-10-31 01:49 · Score: 4, Funny
  
  To defrag? Boy were you lucky--my SE hard drive had a crank to start it in the morning.
  Oh wait: that would have been actually useful. (What, nobody else remembers stiction?)
  
  --
  --- Jason Olshefsky
  Karma: Poser (mostly affected by adding this line long after everyone else did)
6. Re:Autodefrag. (snort) by Anonymous Coward · 2003-10-31 01:50 · Score: 0
  
  bah, you fancy tablet wielding whippersnappers, why in my day we drew our numbers with our bare foot in the snow. uphill. both ways.
7. Re:Autodefrag. (snort) by coolgeek · 2003-10-31 07:11 · Score: 1
  
  Yeah I remember that...It wasn't long before I thought to myself "Who's the machine in this equation anyway?", and plunked down the $400 for the extra floppy.
  
  --
  
  cat /dev/null >sig
8. Re:Autodefrag. (snort) by sharl · 2003-11-01 04:17 · Score: 1
  
  Hard drive? You were lucky. On my Mac Plus I had to write blocks to separate 800k floppies and stack them in the right order for disk toasting.
  
  --
  Clearly I have too much time on my hands.
9. Re:Autodefrag. (snort) by sharl · 2003-11-01 04:20 · Score: 1
  
  A crank handle? I once thought that would make a cool accessory for the side of my Plus. Something to wind while I watched the wristwatch spin (like everytime I clicked a link in Hypercard..)
  
  --
  Clearly I have too much time on my hands.
10. Re:Autodefrag. (snort) by TeamSPAM · 2003-11-01 09:13 · Score: 1
  
  Yes. I remember stiction quite well. Just started college at Drexel with a brand new SE/30. Thank goodness I had Applecare at the time. Think I went through 2 40Mb drives in the first two years I owned it. In those days I felt Applecare was better. It was a lot easier to find computer stores that were authorized resellers and they didn't blink and eye when you dropped off an apple and said it needed to be fixed. These days, I'm not sure I trust the few places left that would honor Applecare. Luckily, I'm a short drive to the KoP mall and an Apple Store.
  
  --
  Brought to you by Team SPAM! where we believe: "Information in the noise!"
11. Re:Autodefrag. (snort) by Anonymous Coward · 2003-11-03 08:50 · Score: 0
  
  I'm sorry, but I find this overused joke to be lame and boring
  IN my day, we didn't have overused jokes. We had to be lame and boring on our own!
What exactly are.... by Creepy+Crawler · 2003-10-30 12:37 · Score: 2, Interesting

MacOS FileID's?

Are they comparible to what Reiser4FS will have? Are they better that XYZ offering in Linux?

I'm seriously interested in what EXACTLY they are. Please spare the fanboy attitude if you do wish to answer..
--
- Mod parent up! by Anonymous Coward (Score:1) Thurs, Nov 31, @13:37
1. Re:What exactly are.... by anarkhos · 2003-10-30 13:13 · Score: 1
  
  http://www.cocoadev.com/index.pl?FileID
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
2. Re:What exactly are.... by anarkhos · 2003-10-30 13:20 · Score: 2, Informative
  
  A more technical explanation: http://developer.apple.com/technotes/tn/tn1150.htm l
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
3. Re:What exactly are.... by Creepy+Crawler · 2003-10-30 13:31 · Score: 1
  
  Ahh, thanks ;-)
  
  After looking through the basics, isn't the FileID something similar Hans did in Reiser? Course in the earlier versions, the "same ID bug" got my /usr/X11R6 directory mixed up with /etc. Let's just say I've not used Reiser3 again...
  --
  
  Mod parent up! by Anonymous Coward (Score:1) Thurs, Nov 31, @13:37
4. Re:What exactly are.... by anarkhos · 2003-10-30 13:38 · Score: 1
  
  I have no idea, you'll have to ask the author.
  
  If you have multiple files or directories referring to one file that sounds more like an inode than a FileID.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
5. Re:What exactly are.... by stripes · 2003-10-31 06:43 · Score: 1
  
  After looking through the basics, isn't the FileID something similar Hans did in Reiser?
  
  Any filesystem that supports hard links has to have something like a Mac FileID. Traditional Unix filesystems call them "inode numbers" or "i-numbers", try "ls -i" sometime.
  On Mac OS you can open a file given it's FileID but on most Unixes you can not (I assume OSX can, and some versions of SunOS/Solaris can as pat of one of the backup products). It opens a small security hole where you put files in a directory that denies permission to people but the files themselves allow it and you didn't want them to have permission (or only wanted them to have permission if they went through a specific program that knew how to make the filename). Mac OS can also map the FileID back into a name which most Unixes can't (Plan 9 can, and claims it is generally a great benefit, and far far simpler then they thought it would be back when the Plan9 folks invented Unix and decided it would be too hard to write and not worth it).
  In short Unix has something exactly like FileIDs, but you can't use them in all the same ways despite the exact equivalence at the filesystem level.
6. Re:What exactly are.... by anarkhos · 2003-10-31 18:56 · Score: 1
  
  In short Unix has something exactly like FileIDs
  BULLSHIT!!!
  FileIDs are not inodes. They are NOT equivalent as I pointed out elsewhere.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
7. Re:What exactly are.... by stripes · 2003-11-01 08:07 · Score: 1
  
  FileIDs are not inodes. They are NOT equivalent as I pointed out elsewhere.
  
  Um, all I saw you say that one can do with FileIDs that you can't do on most Unixish systems is #1 open files directly by them, and #2 convert them to a name without a full scan of the filesystem. Am I wrong?
  If I'm right they are equivalent data structures, but the operations you want are not normally available. Wit pretty minimal work one could put both operations into an Open Source Unixish system. I would say 3 hours work tops to "open by inode" (which SunOS and Solaris both have), and I think about a week for fd2name but I would have to reread some papers or even try it to be sure.
8. Re:What exactly are.... by otuz · 2003-11-01 13:29 · Score: 1
  
  HFS FileID:s are much like "INTEGER PRIMARY KEY UNIQUE" columns in SQL.
9. Re:What exactly are.... by anarkhos · 2003-11-02 20:32 · Score: 1
  
  Firstly I'd like to apologize for acting like some ass with tourette's syndrome.
  
  Secondly the problem is the roles are in reverse. The FileID is like the path in UFS. You don't have a situation where multiple paths can point to one FileID because the path is more like a file attribute. In other words the FileID (or CNID) has a path, not the other way around.
  
  On UNIXish filesystems it's the path which has the inode, not the other way around.
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
JOUNRALLING my boy JOURNALING by goombah99 · 2003-10-30 13:01 · Score: 3, Informative

According to the ARS writeup, this feature is on only when journalling is on. This makes total sense, since journalling prevents an incomplete or unverified write from being used.

--
Some drink at the fountain of knowledge. Others just gargle.
1. Re:JOUNRALLING my boy JOURNALING by notfancy · 2003-10-31 03:03 · Score: 1
  
  It works whether or not journaling is turned on. However, the code has a bug in hfs_relocate: hfs_global_shared_lock_acquire(hfsmp); if (hfsmp->jnl) { if (journal_start_transaction(hfsmp->jnl) != 0) { return (EINVAL); } } if the the transaction can't be started, the acquired HFS lock never gets released. After this, the code is careful to record the error and jump to a common epilog that unlocks the HFS subsystem. I'd rather not turn journaling on.
I am just curious, by Anonymous Coward · 2003-10-30 13:02 · Score: 0

Can you not install Mac OS X on a UFS partition?
1. Re:I am just curious, by anarkhos · 2003-10-30 13:17 · Score: 1
  
  You can but it's SLOOOOW
  
  --
  >80 column hard wrapped e-mail is not a sign of intelligent
  >life
2. Re:I am just curious, by Ffakr · 2003-10-30 17:29 · Score: 1
  
  The biggest problem with using UFS is poor compatibility with Classic and multi-forked classic files. Specifically, there is NO UFS support in Classic.
  You can use UFS, but you better not run anything but pure OS X.
  
  --
  I'm not feeling witty so bite me
think outside the /. by BortQ · 2003-10-30 13:11 · Score: 4, Insightful

It seems as if the /. crowd isn't all that impressed by this advance by apple.
Well that's fine. The real upside of this is for people that have never heard of /. and don't really know what a hard drive is, let alone know how to defrag one.
Previously these people would just go forever without defragging. Now they can still do that, because Apple is doing it for them behind the scenes.
This is yet one more example of Apple's winning philosophy: Keep it simple, make it better.

--

A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
1. Re:think outside the /. by Anonymous Coward · 2003-10-30 18:31 · Score: 0
  
  Uhhh, the question is why is it fragmented in the first place? By design, most modern file systems suffer almost no fragmentation at all. This looks for all the world like a stopgap band-aid for a legacy file system. There's certainly nothing wrong with that of course. But it is not all that technologically interesting.
2. Re:think outside the /. by Brandybuck · 2003-10-30 19:53 · Score: 1
  
  With HFS+ and UFS, you simply don't need to defrag. The very nature of the filesystems keeps things from getting too fragmented. It might get you some trivial performance advantages for some specialized activities, but for everyday use it's simply not needed.
  
  The upside is that 95% of this is simply marketing to wow the Windows users raised on FAT. IMHO.
  
  --
  Don't blame me, I didn't vote for either of them!
3. Re:think outside the /. by ploiku · 2003-10-31 05:44 · Score: 1
  
  > With HFS+ and UFS, you simply don't need to defrag.
  
  This is a bizarre statement, given that Apple obviously believes that HFS+ needs at least _some_ defragging.
  
  > The upside is that 95% of this is simply marketing to wow the Windows users raised on FAT. IMHO.
  
  Except Apple isn't marketing it anywhere that I can see.
Damn! by csoto · 2003-10-30 14:39 · Score: 4, Funny

That's gonna mess up my UT 2003 ranking! I work hard for those frags! Every one of them!

--
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
XP has a similar feature by Doc+Squidly · 2003-10-30 14:50 · Score: 2, Interesting

Windows XP has a similar feature that waits a until the computer is not in use for a certain amount of time. It would make sense that Apple would give users the same option.

--
I think I think, therefore I think I am.
1. Re:XP has a similar feature by Trillan · 2003-10-30 14:58 · Score: 1
  
  Oh, neat. Where's the option? Or is it always on?
2. Re:XP has a similar feature by The+Munger · 2003-10-30 15:09 · Score: 1
  
  Well I couldn't find the option, but here's a page for setting up defrag at start-up, and scheduling defragging manually:
  http://www.kellys-korner-xp.com/xp_defrag.htm
  
  --
  Refuse to make a statement in your sig!
3. Re:XP has a similar feature by Anonymous Coward · 2003-10-31 05:01 · Score: 0
  
  This is /. Every one of you dorks would have a completely fragmented drive. You never leave your workstations..
4. Re:XP has a similar feature by Anonymous Coward · 2003-10-31 15:23 · Score: 0
  
  Oh!!! So is that why the damn computer would randomly start crunching at the hard drive with wild, reckless abandon every night? Jesus, that was annoying. Finally went back to Windows 2000 on that machine, because of this and because XP refused to power it down on shutdown. Piece of shit.
information by djupedal · 2003-10-30 14:53 · Score: 3, Insightful

Try this...

...and this...
No such limits. by Trillan · 2003-10-30 14:55 · Score: 3, Informative

The source code is posted to that thread; the only conditions are (1) 3 minutes after the system time starts (i.e. avoid doing so when booting up), (2) less than 20 MB of size, (3) file isn't already opened.

The only negative consequence is a possible speed hit, though. There's no danger.

I'm pretty impressed by this. Sure, it's been done before. Sure, there are more elaborate methods. But this is just a simple little lump of code that'll defragment the worst files most of the time.
1. Re:No such limits. by macmurph · 2003-11-02 21:06 · Score: 1
  
  The only negative consequence is a possible speed hit, though.
  
  Isn't the point of keeping your drive defrag'ed to increase the performance of reading and writing?
  
  With 200+ gig hard drive capacities becoming more ubiquitous, the performance hit of on the fly defragging is worthwhile. Over the long run, it improves performance of a machine to keep it defragged, right?
2. Re:No such limits. by Trillan · 2003-11-03 13:39 · Score: 1
  
  Apple's choice of algorithm defrags files as it encounters them. If you are upgrading a drive, it may have a lot of fragmented files that need to be defragmented. So initially, it will be very slow.
  
  Once the code has been exercised for a while, yeah, it'll be much faster.
Darin 7 by Anonymous Coward · 2003-10-30 14:57 · Score: 0

Hi,

I installed Darren 7 on my Power Mac G3/450. It is so blazing fast in text mode, I can't fathom why Mac OS X lags so slowly. I can't wait for 7.1, which should be in line with FreeBSD 4.9!

Seeya later,
M4C H4ck4R
1. Re:Darin 7 by ColMustard · 2003-10-30 21:37 · Score: 1
  
  Did you just say what I think you said?
  
  You are wondering why an operating system in text mode is faster than the same operating system when it has to render a graphical user interface?
  
  Bleh. This is probably a troll because you misspelled Darwin twice. Or you might just be a bit slow, which would be in line with your comment.
  
  --
  Moof.
really now... by Anonymous Coward · 2003-10-30 14:58 · Score: 0

I guess that your experience must just be the one and only possible way that ALL of us experience Panther, right? You really come off as a troll just LOOKING to start a useless little flame war....tsk tsk
How to defrag your entire hardrive using this by goombah99 · 2003-10-30 15:15 · Score: 2, Informative

sudo find / -exec wc {}
this should defrag all of the 20M or less files on your hard drive.
it locates every file, opens it and reads every bite then closes it.
This should force the defragger to run on all files under 20M. Not that technically the defragger only activates when the file is broken into more that 8 extent regions. So this does not actually defrag everything.
but its also possible that having the file broken into less extents is harmless. first because the the first 8 extents are the fasttes to access in HFS+ and second its theoretically possible that on a multi-headed disk drive that having the file slightly fragmented might be good. Larger numbers of frags than read head would be bad of course

--
Some drink at the fountain of knowledge. Others just gargle.
1. Re:How to defrag your entire hardrive using this by Anonymous Coward · 2003-10-30 16:17 · Score: 1, Informative
  
  this should defrag all of the 20M or less files on your hard drive.
  
  That would be insanely wasteful. Remember, OS X is a UNIX system. That means that the vast majority of the files on the computer are smaller than the block allocation size of the filesystem. In other words, most files on your disk not only aren't fragmented, but are too small to ever fragment.
2. Re:How to defrag your entire hardrive using this by Anonymous Coward · 2003-10-30 16:53 · Score: 0
  
  Okay then how about this then
  sudo find / -atime 100 -type f -exec wc {}
  this will only test read files acessed in the last 100 days . I leave it to you to screen for block size (presumably you want to test files > 8 blocks)
3. Re:How to defrag your entire hardrive using this by Anonymous Coward · 2003-10-31 01:44 · Score: 0
  
  this will only test read files acessed in the last 100 days
  
  Idiot. Accessed just means opened for reading. Everything is opened for reading. You want -mtime, meaning opened for writing.
  
  Step away from the terminal before you hurt yourself.
4. Re:How to defrag your entire hardrive using this by Anonymous Coward · 2003-10-31 07:37 · Score: 0
  
  Uh no. I want just accessed. if you havent READ it in the last 100 days its probably not worth defragging. You sir are the Idiot.
5. Re:How to defrag your entire hardrive using this by stripes · 2003-10-31 07:42 · Score: 2, Informative
  sudo find / -exec wc {}
  
  That'll also read them even if they don't need to be defraged. This may be better:
  sudo find / -exec head {} >/dev/null \;
  
  Left as an exercise to the reader:
  
  only run on stuff less then 20M (not that that will save you much, but it is a good way to learn how to use random tools)
  
  Sort by access time, and head the files in that order so the most recently (and hopefully frequently) accessed files have more chance of being defraged then the older files
  
  Parallelise it, and see how much slower (or faster!) it goes with diffrent numbers of concurrent accesses.
  
  Slap a GUI on it and sell it for $12 as shareware
6. Re:How to defrag your entire hardrive using this by Anonymous Coward · 2003-10-31 10:28 · Score: 0
  
  You are not the only entity that opens files for reading, shitwit. Everything in /etc--tens of thousands of files--is opened for reading constantly.
  
  God, what a dim bulb. What an ultra-maroon. What a nin-cow-poop.
The defragger already allows partial fragmentation by goombah99 · 2003-10-30 15:18 · Score: 1

Notice that the defragger only activates if the file is fragmented more than 8 ways. thus this mutli-read head issue is already accounted for. if you fragment the file into more extents than you have read heads this would presumably be bad. but perhaps 8 is the optimal number or close to it? its also faster because of the way hfs stores the file table that beyond 8 the lookup time increases.

--
Some drink at the fountain of knowledge. Others just gargle.
XP way maybe not so good. by goombah99 · 2003-10-30 15:34 · Score: 2, Interesting
Windows XP has a similar feature that waits a until the computer is not in use for a certain amount of time. It would make sense that Apple would give users the same option.
I'm Not sure the windows approach is really better. Notice that the apple approach is more minimalist in moving files.
- If you aren't actively using a file it wont get moved--that's good since moving a file always entails a tiny but finite risk of corruption.
- (notice that the apple method relies on journaling to save your butt if the computer crashes mid write.)
- The apple program doesn't even activate unless the file is fragmented more than 8 ways-- again minimalist.
- the windows program wont be able to move files that are currently open (I would guess). and of course those are exactly the files you will want to defrag most!
- the windows program is probably taking a risk that some baddly written program will suddenly decide to read or write to a cached but now dead file pointer.
- apple gets away with this at almost no cost by defragging files it was going to read in anyhow for another reason. thus the read adds no time. For many user applications probably wont be going any other disk reads right after that. (e.g. read in the word doc and start editing it).
--
Some drink at the fountain of knowledge. Others just gargle.
1. Re:XP way maybe not so good. by drsmithy · 2003-10-30 16:40 · Score: 2, Interesting
  
  If you aren't actively using a file it wont get moved--that's good since moving a file always entails a tiny but finite risk of corruption.
  Not if you do it intelligently (copy data, compare to original, delete original as an atomic operation).
  (notice that the apple method relies on journaling to save your butt if the computer crashes mid write.)
  That mightn't save your file data. AFAIK HFS+'s journalling is metadata only.
  the windows program wont be able to move files that are currently open (I would guess). and of course those are exactly the files you will want to defrag most!
  OS X allows moving the physical data around of an open file ?
  the windows program is probably taking a risk that some baddly written program will suddenly decide to read or write to a cached but now dead file pointer.
  How do you figure that ?
  apple gets away with this at almost no cost by defragging files it was going to read in anyhow for another reason. thus the read adds no time.
  And Windows (assuming it actually does it) "gets away with it" by doing all this when the machine is idle. And while the read adds no time, the subsequent seeking, rewriting and deleting certainly does.
2. Re:XP way maybe not so good. by Anonymous Coward · 2003-10-30 17:06 · Score: 0
  
  OS X allows moving the physical data around of an open file ?
  yes! that's how it works. when you open the file it defrags it. The program getting the data will get the new file location. If the file is of course open by another app already it cant move it. This also answers the next question: it hard to defrag a whole disk if apps have files open since you cant move those for fear of a program trying to access the wrong disk sectors. thus defragging upon open is a cool idea.
  Journaling of meta data is all you need. the defragged ffile is written out. if the computer crashed during the update of the file table youre hosed. Journalling saves your butt.
3. Re:XP way maybe not so good. by drsmithy · 2003-10-30 19:20 · Score: 1
  
  yes! that's how it works.
  Ah, I think you'll find it just moves the file to a new, contiguous area and *then* opens it.
  Journaling of meta data is all you need. the defragged ffile is written out. if the computer crashed during the update of the file table youre hosed. Journalling saves your butt.
  If the machine crashes while the OS is halfway through writing a file, it's entirely possible for the file to become corrupted, or not all the new data to be written. Metadata journalling won't help you then.
4. Re:XP way maybe not so good. by stripes · 2003-10-31 07:07 · Score: 1
  
  Not if you do it intelligently (copy data, compare to original, delete original as an atomic operation).
  
  The algo Apple uses is get a write lock on the file, write the current data out as if it were being appended (which attempts to write it in as few chunks as possiable), then get a read lock on the file, then free up the "old part" of the file and adjust meta data to make the newly written blocks be the start of the file. I assume something prevents the file from looking twice as long as it should during the copy, but I didn't see it in the code (it is probbably as simple as "ExtendFileC doesn't update that kind of metadata anyway lunkhead!"). That is done in the kernel context of the process that did the open, so it delays the return of that syscall, which is a shame.
  OS X allows moving the physical data around of an open file ?
  
  Yes since they are only logically addressed! It will prevent writes during the operation (and reads during a very small bit of time).
  And while the read adds no time, the subsequent seeking, rewriting and deleting certainly does.
  
  The read adds time if the process wouldn't have read that part of the file anyway (for example if it reads a bit of header data and closes the file). The rewriting may well be absorbed by the buffer cache (it is elligable for it) along with it's seeks and the time it later takes to actually happen might end up being zero (file deleted), or face no contention for the disk and end up being free. The deleting goes to the journal, but since lots of other things go there all the time that may be "mostly free".
  So the costs may be low, but are more likely to be percieved then something that does it when the box is idle. Of corse there is the chance that the box is never idle. For example a 24/7 server that gets used 24/7, or a laptop that is never powered up except when it is in use. So delaying something like that "until idle" might delay the benifits of defrag not just "for a while" but "forever".
  I donno which is actually better. I think with some tuning to only do "as you go defrag" when there isn't a lot of pending I/O could definitly make it the more likely winner, but it will still depend on usage patterns. One could also tune the "only when idle" method to do "just a little" if it has been "too long" since the last time it was idle.
No youre wrong, parent is right by Anonymous Coward · 2003-10-30 17:26 · Score: 0

If you aren't actively using a file it wont get moved--that's good since moving a file always entails a tiny but finite risk of corruption.
>Not if you do it intelligently (copy data, compare to original, delete original as an atomic operation).
err no. you're showing a fundamental misappreciation of the problem. Every time you move a file you risk corrupting it.
It does not matter if you double check what you wrote, because that only decreases the chance of making an error. it does not eliminate it. you might make the same read error twice in a row.(e.g. to make this plausible imagine say a weak magnetization that flips after a temperature change later that night). or perhaps you may have read the file wrong in the first place. or something might go wrong when you are updating the file allocation table or there might be some bug in the code that makes an error.
the point is that if you just left the file alone inthe first place its safer.
thus the apple approach of only defragging a file in active use and leaving all the other's alone may be preferred to a blanket de-fraggmenting of a disk.
furthermore, when was the last time you tried de-fraggmenting a 500GB disk? do you have any clue how many days this would take??? The apple approach of doing it just-in-time makes a lot of sense. It follows the same logic as jounaling, which is in part a response to no having to fsck a 500GB disk.
1. Re:No youre wrong, parent is right by drsmithy · 2003-10-30 20:10 · Score: 2, Interesting
  
  Every time you move a file you risk corrupting it.
  By the logic you seem to be applying, every time a file is accessed you "risk" corrupting it.
  It does not matter if you double check what you wrote, because that only decreases the chance of making an error. it does not eliminate it. you might make the same read error twice in a row.(e.g. to make this plausible imagine say a weak magnetization that flips after a temperature change later that night). or perhaps you may have read the file wrong in the first place. or something might go wrong when you are updating the file allocation table or there might be some bug in the code that makes an error.
  Please explain why these events are more likely to occur to a file's new location than the old one.
  the point is that if you just left the file alone inthe first place its safer.
  Why ? It's equally as vulnerable to all the same one-in-a-billion events.
  thus the apple approach of only defragging a file in active use and leaving all the other's alone may be preferred to a blanket de-fraggmenting of a disk.
  So, assuming you're correct, the Apple method is preferred because it (minutely) increases the chances of corrupting the files you access, as opposed to some random file ?
  Tell me, which file do you think you're more likely to care about - a random file X from the set of all files on the drive or a random file Y from the set of files you deliberately access ?
  furthermore, when was the last time you tried de-fraggmenting a 500GB disk? do you have any clue how many days this would take??? The apple approach of doing it just-in-time makes a lot of sense. It follows the same logic as jounaling, which is in part a response to no having to fsck a 500GB disk.
  After many years of experimenting with defragging and not defragging, I've come to the conclusion that it makes bugger all difference whether a disk is fragmented or not. If I can't tell the difference, it's not worth doing.
2. Re:No youre wrong, parent is right by ColMustard · 2003-10-30 21:32 · Score: 1
  
  "I've come to the conclusion that...it's not worth doing."
  
  Good answer. Defragging a 500GB disk really isn't worth it, you got that much.
  But if the OS is going to do it in the background with practically zero overhead, even without any other benefits I say go for it!
  
  --
  Moof.
3. Re:No youre wrong, parent is right by drsmithy · 2003-10-30 21:52 · Score: 1
  
  Good answer. Defragging a 500GB disk really isn't worth it, you got that much.
  It's hardly the 500G aspect. Defragging the 20G hard disk in my laptop shows no discernable benefit, even when going from "99% fragmentation" to "1% fragmentation".
  But if the OS is going to do it in the background with practically zero overhead, even without any other benefits I say go for it!
  Except it will - by definition - have overhead. The more files a user is manipulating, the more overhead it will have.
4. Re:No youre wrong, parent is right by ploiku · 2003-10-31 05:27 · Score: 1
  
  In large part that's because you aren't using most of those files. Probably 99% of your files can be fragmented (even heavily) and it won't make a difference because they aren't used (often or at all).
  
  "Make the common case fast",
  
  That's what this is all about. Defragment only the files that you actually _use_.
  
  Of course, since there are performance requirements to doing this on the fly, it still has limitations. (i.e. nothing over 20MB, nothing with 8 fragments).
  
  The hotfile clustering has the same idea - put only the files read the most into the hotband. Same sort of limitations apply (1.2MB, read-only files)
5. Re:No youre wrong, parent is right by ColMustard · 2003-10-31 07:49 · Score: 1
  
  "Except it will - by definition - have overhead. The more files a user is manipulating, the more overhead it will have."
  
  *sigh* We've already talked about this. Since it only does it with files that really need it (over 8 fragments), it doesn't need to do it every time a file is opened. The speed is saved when the file is defragged and therefore nothing needs to happen. But like I said, for your understanding I was ignoring all the other benefits. You've simply gone and turned one of the benefits into something bad.
  
  My first point was, you think defragging is pointless. This new system doesn't defrag the entire drive, just the files you use, and it does it with practically no loss, so why not?
  
  --
  Moof.
Re:hoo yah by Anonymous Coward · 2003-10-30 17:33 · Score: 0

Good thing it doesn't defag. Otherwise Apple would lose a large part of their market.
always good to keep your porn collection running.. by Anonymous Coward · 2003-10-30 18:03 · Score: 0

..at full speed.

Thank you Apple for thinking of my porn needs.
What about secure delete? by Anonymous Coward · 2003-10-30 20:15 · Score: 0

If the file is "cloned" on opening and the user then closes it and performs a "secure empty trash", didn't this "feature" just leave a copy of the data behind that could be reconstructed?

That defeats the purpose of "secure empty trash". It doesn't matter to me, I like the idea, but maybe someone else wants the option to disable it for security reasons.
1. Re:What about secure delete? by Anonymous Coward · 2003-10-31 07:14 · Score: 0
  
  Finally. Some sense of intelligent discourse on this topic. I believe you are correct.
Not quite right (clarification) by ploiku · 2003-10-30 22:06 · Score: 5, Informative

The summary appears to not be quite right.

To clarify, there are 2 separate file optimizations going on here.

The first is automatic file defragmentation. When a file is opened, if it is highly fragmented (8+ fragments) and under 20MB in size, it is defragmented. This works by just moving the file to a new, arbitrary, location. This only happens on Journaled HFS+ volumes.

The second is the "Adaptive Hot File Clustering". Over a period of days, the OS keeps track of files that are read frequently - these are files under 10MB, and which are never written to. At the end of each tracking cycle, the "hottest" files (the files that have been read the most times) are moved to a "hotband" on the disk - this is a part of the disk which is particularly fast given the physical disk characteristics (currently sized at 5MB per GB). "Cold" files are evicted to make room. As a side effect of being moved into the hotband, files are defragmented. Currently, AHFC only works on the boot volume, and only for Journaled HFS+ volumes over 10GB.
Oh, missed one... by Trillan · 2003-10-30 22:50 · Score: 1

I'm a bit less sure of this one, but I think the file must be severely fragmented (i.e. into 8 pieces).
Just Ask your buddies to PAYPALZ THE MONIEZ by Anonymous Coward · 2003-10-31 02:55 · Score: 0

Maybe you can even lock down the forums some more and not provide any more benefits for subscriptors beyond PDF's of the main articles (I'm sure people were clamoring for that one).

WOW THAT'S SOME SERVICE. WHERE DO I PAYPALZ THE MONIEZ? (@)>
Defensive? by Doc+Squidly · 2003-10-31 06:53 · Score: 1

No need to get defensive. I was just trying to suggest that Apple would have a setting that would wait until the computer was not being used. Apparently you feel threatened by the mere mention of Windows. If you ask me the whole PC/Mac debate is going nowhere. It's just a juvenile pissing contest.

--
I think I think, therefore I think I am.
'Multiple Heads' misunderstood by MarcQuadra · 2003-10-31 09:45 · Score: 1

Alright, there ARE multiple heads, but there is still only 1 head to each platter-surface, and all the heads on all the platters are connected at the base, so they cannot move independently. You ARE better off defragged than not, but even better would be to 'arrange' files based on access paterns.

I tell you this, I notice quite a speedup after I perform a full-backup-and-restore, the only way to defrag most Linux filesystems. I saw loading OpenOffice take 7 seconds before, and 3 after.

When I load Mozilla it has to read in a LOT of other files, a proper filesystem would log that and try to move those files closer to each other. ReiserFS is trying to implement something like this, I believe, they are marking the 'temperature' of inodes based on access patterns.

--
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
ColMustard's Question Hour - Part 2 by MarcQuadra · 2003-10-31 09:59 · Score: 1

Dear ColMustard,
I was wondering why my Ford Escort doesn't get good pickup when I've got it packed with bricks. It goes fine when it's just me and the seats, but once I pile those bricks in it's so laggy! Do you think I should put brighter headlights in, or should I change the blinker fluid?

--
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Microsoft discovers metadata by Slur · 2003-10-31 11:15 · Score: 1

I'm still confused as to why metadata isn't being taken seriously by the rest of the computing world.
Actually, if you read some of the articles about Microsoft's preview of Longhorn you'll see that they're developing a new filesystem that not only incorporates metadata but takes it to the level of a relational database. Expect to see many articles on how metadata is the best innovation to come from Microsoft since Windows 95.

--
-- thinkyhead software and media
interaction with "secure" delete by mjs · 2003-10-31 12:18 · Score: 2, Interesting

I wonder how that interacts with the "secure" delete. Does it seeks out previous copies of the file and securely delete them too? That would be quite a feat.

(Also, has anyone confirmed that the code snippet is actually executed?)
hay mistar CEZar by Anonymous Coward · 2003-11-03 15:53 · Score: 0

eet MOR cok k? 3 WWW.stupidfag.COM
HFS+ is very good, but there's still more to do by obirt · 2003-11-08 13:47 · Score: 1
I can still think of a few things that would make a good file system great.
- Access control lists, and permission inheritance to equal or better NTFS. Why? So that hosting of SMB/CIFS network shares could maintain full permissions and inheritance.
- Implementing fully or partly the BSD LFS file system. Some general information can be found here or source from the NetBSD source tree.
- Volume and/or directory quotas
--

I use to be indecisive, but now I'm not so sure.