Defrag in OS X?

[hypocampers]

Issue from the terminal "df -k", take alook (in general) at the "/" filesystem this will tell you not only what size your root filesystem is but that Darwin can see and deal with almost anysize filesystem.

I have a small but 50+ GB filesystem for root, crackers I know, and I've used 30Gb of it, how you supposed to back that up?.

What should happen from a UNIX point of view, is and "fsck -Y" from either sudo or the root account

However its been whispered that MacOSX does something else with the dam disk so fsck (it works for all other UNICES) is not totaly functional.

I also see large chunks of my disk dissappearing when I make movies or use iDVD and then junk the stuff when recorded off to media. I am unable to recover this lost disk space.

[hypocampers]

Issue from the terminal "df -k", take alook (in general) at the "/" filesystem this will tell you not only what size your root filesystem is but that Darwin can see and deal with almost anysize filesystem.

I have a small but 50+ GB filesystem for root, crackers I know, and I've used 30Gb of it, how you supposed to back that up?.

What should happen from a UNIX point of view, is and "fsck -Y" from either sudo or the root account

However its been whispered that MacOSX does something else with the dam disk so fsck (it works for all other UNICES) is not totaly functional.

I also see large chunks of my disk dissappearing when I make movies or use iDVD and then junk the stuff when recorded off to media. I am unable to recover this lost disk space.

[strobe]

I do not suggest using UFS for several reasons.

UFS doesn't support HFS+ attributes and instead stores them in a separate file. This means UFS ends up being painfully slow unless you're only using UNIX apps.

UFS doesn't support FileIDs so your aliases will break like symlinks.

There aren't many 3rd party utilities for UFS in case something goes wrong. Yes, you shoudl always backup, but you've been warned.

[Urbansory]

cool, thanks for the advice, i found a older thread that had other members describing their problems with th format. Better knowing now than later.

[ByerlyRips]

UFS doesn't support HFS+ attributes and instead stores them in a separate file. This means UFS ends up being painfully slow unless you're only using UNIX apps.

You're saying it will run normally only if you're using native unix apps? So if you're using a carbon or cocoa app it will run slow; or just a classic app?

[hypocampers]

I started out using UFS, only because I am UNIX admin. However it took and age to load OSX and subsequent upgrades to an unacceptable amountg of time and so have moved to HFS. The Mac seems happier with HFS, even though its limited in some ways. As mentioned months ago none of the standard UNIX "dump" and "restore" work properly (they should!). If "dump" and "restore" would work properly there would be no need for all the chatter about backing up, backup would have been solved freely from day one.

The applications seemed to work ok under UFS, but this was in the days of 10.0, but things like update_prebinding could take ages and there seemd to be a general slow down in performance over a few months or so.

In the end Apple will have to fix HFS so its more in line with other UNIXs, otherwise there will be a day when the lack of mixed case support will come home to roost. In a heterogenious environment of UNIX machines the Mac will run into silly but intractable problems.

[strobe]

HFS+ is faster for a number of reasons. Searching for files on HFS+ volumes is probably faster due to a) files being indexed by ID and b) the catalog file being organized in a b-tree.

As for UNIX backup methods the problem here is UNIX lacks an API to handle an arbitrary number of file attributes and forks. This isn't Apple's fault, it's just the sordid 30yr history of UNIX being one giant hack. I mean next you'll complain that UNIX doesn't follow Aliases or can't use FileIDs or FSRefs. UNIX lacks these, always has, always will. For example UNIX will never support creation dates, it wasn't in the original spec some 30 years ago.

PS: I hate UNIX

Not that the toolbox is perfect. However Apple revised large portions of their API to improve the user's filesystem experience. For example functions which used file paths as arguments were deprecated to encourage programmers to treat file paths as variable and not constant. Standards like POSIX make this impossible in the UNIX world. In fact UNIX lacks API abstraction for a lot of things and instead relies on formats which as a result cannot be changed.

Anyway I hope Apple creates a new filesystem which incorporates all of the advantages of UFS and HFS+. It's clear that Apple is developing a journaled version of HFS+. That isn't the same, but it's a good stop-gap.

[hypocampers]

I have to say I do like the performance of HFS, but it does this by making sacrifices. To suggest that HFS is better because of like (a) files being indexed by ID and b) the catalog file being organized in a b-tree) is pooh.

Sun , SGI, IBM, HP, DEC, Linux filesystems...etc etc are all capable (much more capable that HFS), not forgetting things like Veritas VFS and its ability to do online database (Oracle etc) backups (without taking the application down).

All the above can back themselves up properly without reference to any front end which sits on top of it, UNIX manufacturers take the view that basic backup is provided by the base operating system by default, except Apple.

Journalled file systems have been around for donkeys nothing new and are slow, AIX has had it for a decade by default, wherever we were allowed we disabled it using SMIT.

Getting rid of case insensitive stuff is paramount in terms of UNIX interoperability or for that matter any form of filesharing with other OSs, getting out from under the mantle of having the front end dictate how a filesystem will be re-written will make the MacOSX filesystem much more compatible with other UNIX vendors.

Having POSIX around is/was there for a reason, good or bad you take an educated choice, its does however make a lot of things work between platforms of different vendors and thats the knub, which is where Apple should have started rather than take the MicroSoft approach of taking its own seet way and force everybody down their trap, Apple isn't big enough to do that....yet.

Do we mean "business" with this or what, we can't pussyfoot around pretending were the best when we can't take care "step 1" properly. If you want Apple to move into the mainstream UNIX server environment HFS will not cut it. Ok its not far off, I think MacOSX is fab I love it, but we are preaching to the converted here. Convincing the 2nd amd 3rd rate IT managers (MicroSoft managers really) is an uphill struggle that requires more that this one pittyfull person (me) in Aberdeen Scotland to convince IT plonkers to move to something much more inovative, its more than just hard its a 10 to 15 year struggle.