[SpaceMonkey]

Do the developer machines use HFS+? I'm just curious.

[TETENAL]

Yes, they do.

[Athens]

Can OS X be installed on Fat32? I know it can read it but to run off it, I havent tried that yet. If so I wonder if you could daul boot OX X and Windows XP from the same hard drive partition.

[P]

No, it can't - at least not as of 10.4. OS X can "root and boot" from HFS+ and UFS, as well as various read-only filesystems like UDF (DVDs) and ISO 9660 (CDs).

BTW, it's strongly discouraged to use Fat32 for XP. Use NTFS. Seriously. Fat32 is a horrible FS.

[OreoCookie]

FAT32 doesn't support essential features OS X (and any modern OS) needs such as ownership and permissions.

[ghporter]

FAT32 is a poor but common denominator in terms of sharing files between platforms. I'd like to see something akin to HFS+ and NTFS come along that's "agnostic" enough that both Apple and Microsoft would buy into it as an alternative format. It would have to support all the necessary features for tracking permissions and such, and probably support both journaling and whatever new "fault tolerance technology" comes down the pipe. Essentially, the market is no longer as black and white as it used to be, and the user communities NEED a filesystem/format that any platform can see and use effectively as a secondary or external drive.

Oreo, do you know if there's a Linux format that both Windows and Mac OS can see and use that's advanced enough for booting a Mac from?

[tooki]

ext2, ext3, ReiserFS... Linux has a smattering of great filesystems.

That said, if Windows can manage to work on FAT32, it should be able to run on HFS+ magnificently. Windows could probably boot off of a toad if you wired it up.

tooki

[Athens]

Originally Posted by P

No, it can't - at least not as of 10.4. OS X can "root and boot" from HFS+ and UFS, as well as various read-only filesystems like UDF (DVDs) and ISO 9660 (CDs).

BTW, it's strongly discouraged to use Fat32 for XP. Use NTFS. Seriously. Fat32 is a horrible FS.

Ya NTFS is way better but if OS X could boot from it then It would have been worth while trying it out. OS X cant boot from NTFS and I doubt OS X will ever have read write access to it which is why I asked about Fat32

[Targon]

My opinion on NTFS from use in the real world is that it is a terrible file system. NTFS is a file system which fragments files after a single file copy on a freshly formatted disk. After a few to many copy operations one should look at how fragmented a disk becomes. Worse, when you decide to copy this data to a newly formatted NTFS disk you will noticed the file fragmentation is also copied across. Erasing a disk and copying data across to it will not provide you with a de-fragmented disk as is the case on HFS+.

I have experimented many times with NTFS with copy operations and then examining the fragmentation, so i can tell you I am not talking BS. I was shocked at how easily this FS fragments files, something i have not seen with HFS+.

[OreoCookie]

Originally Posted by ghporter

Oreo, do you know if there's a Linux format that both Windows and Mac OS can see and use that's advanced enough for booting a Mac from?

Well, out of the box Windows does not support any Linux filesystem, you'd have to install drivers for each. And then you can get a HFS+ driver anyway. The problem is clearly Microsoft again: it has no intention of supporting some common denominator. Also they are trying to collect license fees for devices using the FATxx filesystem. In other words, mp3 players and memory cards as well as digital cameras.

I've never heard of someone who managed to boot OS X from anything but a UFS and a HFS+ filesystem. ext2 is supported via a sourceforge project, but afaik you can't install OS X on ext2 unless Apple includes this option during installation. Technically I don't think it would be very difficult to do that.

Also ext2 (or any other free filesystem) could serve as a replacement for FAT as a common denominator, as drivers are available for both OSes either as open source or freeware. It's a kind of chicken and egg problem, I think, the manufacturers of such devices don't want to make the customer jump through extra hoops to make their favorite device work.

Technically I see many filesystems which could serve as the basis for a Mac, ReiserFS, XFS, FreeBSD's FFS (which is pretty much on par with the other two). I'm sure if MS supported a common denominator, so would OS X.

[Maflynn]

Even MS is moving away from fat32, so I don't think apple would even consider embracing it. Also I think that HFS+ is already intergrated into the architecture of the OS, there's little reason to change it. Don't forget Apple is not creating a new OS for the hardware, they've been keeping parallel copies in development that means all pieces should be the same - even the file system.

For the record, I've not had issues with NTFS, does it fragment a file right of the bat, I don't know. Do I care, no. It works. In my job it matters not that my spreadsheet is fragmented over 50 times, just that its there is the important thing.

Mike

[Athens]

Originally Posted by Targon

My opinion on NTFS from use in the real world is that it is a terrible file system. NTFS is a file system which fragments files after a single file copy on a freshly formatted disk. After a few to many copy operations one should look at how fragmented a disk becomes. Worse, when you decide to copy this data to a newly formatted NTFS disk you will noticed the file fragmentation is also copied across. Erasing a disk and copying data across to it will not provide you with a de-fragmented disk as is the case on HFS+.

I have experimented many times with NTFS with copy operations and then examining the fragmentation, so i can tell you I am not talking BS. I was shocked at how easily this FS fragments files, something i have not seen with HFS+.

GOD DAM IT I HATE WHEN I SPEND A LOT OF TIME ON A POST AND I GET LOGGED OUT AND LOSE IT ARRR

Ive used NTFS as much as HFS+ over the last 5-6 years and I can tell you Fat, Fat32, HFS, HFS+ all have giving me headaches with getting corrupt. NTFS is the only one that has not once for me. NTFS does get fragmented, but thats when people are using compression, and filling the hard drive up. HFS+ also gets fragmented. So I think its a silly issue.


http://www.digit-life.com/articles/ntfs/

Part 2. Features of NTFS defragmentatoin
Let's return to one interesting enough and important moment - NTFS fragmentation and defragmentation. The situation with these two concepts at the moment can not be called satisfactory in any way. At the very beginning it was said that NTFS is not subject to file fragmentation. It is not exactly so and the statement was changed - NTFS prevents fragmentation. It is not exactly so either. That is it certainly prevents but... It is already clear that NTFS is a system which is predisposed to fragmentation inspite of official statements. But it doesn't suffer from it. All internal structures are constructed in such way that fragmentation does not hinder to find data fragments fast. But it doesn't save from the physical effect of fragmentation - waste disk heads motions.

To the source of the problem...
As it is known the system fragments files the best way when the free space is being ended, when it is necessary to use small-sized unused space remained from other files. The first NTFS property which directly promotes serious fragmentation appears here.

NTFS disk is divided into two areas. In beginning of the disk there is MFT area - the area where MFT grows (Master File Table). The area occupies minimum 12% of the disk, and the data record in this area is impossible. It is made not to let MFT be fragmented. But when all remaining disk is being filled in - the area is reduced twice. And so on. Thus we have not single pass of the disk ending, but several. In result if NTFS works at the disk filled on about 90% - fragmentation grows greatly.

The incidental result - the disk filled more than on 88% is almost impossible to be defragmented - even defragmentation API cannot transfer the data in MFT area. It is possible that we will not have free space for a manoeuvre.

NTFS works and works and is fragmented - even in the case of free space is far from exhausting. This is promoted by the strange algorithm of finding free space for file storage - second serious omission. The action algorithm at any record is like this: some definite disk range is taken and filled in with a file. It is done by the very interesting algorithm: at first large unused space is filled in and then small one. I.e. the typical allocation of file fragments according to the size on fragmented NTFS looks so (sizes of fragments):

16 - 16 - 16 - 16 - 16 - [back] - 15 - 15 - 15 - [back] - 14 - 14 - 14.... 1 - 1 - 1 -1 - 1...
So the process goes up to most small-sized unused space in 1 cluster, in spite of the fact that on the disk there are also much larger pieces of free space.

Recall compressed files - at active overwriting of the large volumes compressed information on NTFS the huge quantity of "holes" are because of reallocation ñompressed cluster groups on the disk. If any file area began to be compressed better or worse, it is necessary either to take it from a continuous chain and to place in another place or to strap in size reserving unused space.

It is impossible to say that NTFS prevents file fragmentation. On the contrary it fragments them with pleasure. NTFS fragmentation can surprise any person familiar with file system operation in half a year of work. Therefore it is necessary to launch defragmentation. But here all our problems are not ended, they only start...

Means of the decision?
In NT there is standard API defragmentation. It has the interesting limit for files block relocating: it is possible to transfer not less than 16 clusters (!) at once, and these clusters should start from the position16 clusters aligned in a file. In common, the operation is carried out extremely for 16 clusters. The results:



It is impossible to transfer anything in the unused space less than 16 clusters (except compressed files but it is not interesting at the moment).
A file being transferred in another place leaves (in the new place) "the temporarily occupied space" adding it on the size up to multiplicity to 16 clusters.
At attempt to transfer a file the wrong way ("not multiply to 16 ") the result is often unpredictable. Something is just not transferred, but the whole arena is gracefully littered wit "the temporary occupied space". These "the temporarily occupied space" serves for simplification of system restoration in the case of a machine failure and is usually freed half a minute later.
Nevertheless it would be logical to use this API if it is in stock. And it is used. Therefore the standard defragmentation process with the corrections on limitation API consists of the following phases (not necessarily in this order):



Files extraction from MFT area. Not specially - just because it is impossible to put them back. This phase is harmless and even somehow useful.
Files defragmentation. Unconditionally it is a useful process but a bit complicated by limitings of relocatings multiplicity - we have to move files more that it would be otherwise necessary.
MFT, pagefile.sys and directories defragmentation. It is possible through API only in Windows2000, in the opposite case - at reboot, as a separate process like in old Diskeeper.
The addition of files is closer to the beginning - so-called free space defragmentation. It is a terrible process...
If we want to put files on end in the beginning of the disk, we shall put one file. It leaves unused space from its end up to the block (16 clusters) boundary for alignment. Then we put the following, and after that we have the unused space of size less than 16 clusters. Then it is impossible to fill in it through API defragmentation! In result before optimisation the overview of free space looked like this: there were a lot of unused space of the same size. After optimisation - one "hole" at the end of the disk, and a lot of small < 16 clusters ones in the section filled by files. What places are first to be filled in? mall-sized "holes" < 16 clusters taking place closer to the beginning of the disk... Any file slowly built on optimised disk will consist of great number of fragments. Then the disk can be optimised again. And then once again...

Thus there are two about equivalent options. The first one is to optimise the disk often by such defragmentator paying no attention to such great fragmentation of the newly created files. The second variant is not to change anything and put up with regular but much weaker fragmentation of all disk files.

While there is only one defragmentator which ignores API defragmentation and works more directly - Norton Speeddisk 5.0 for NT. When it is compared to all remaining - Diskeeper, O&O defrag, etc. - the main difference is not mentioned. It is just because this problem is carefully hidden. Speeddisk is the unique for today program which can optimise the disk completely not establishing small fragments of free space.

Unfortunately the defragmentator working through API which makes unused space <16 clusters was placed in Windows 2000.

All remaining defragmentators are just harmful at one-time application. If you launched it even one time, you would need to launch it then at least once a month to be saved from new files fragmentation. This is the problem of NTFS defragmentation by old means.

NTFS also supports

Encryption (NT5)
There is a useful possibility for people who are troubled about their secrets - each file or directory can also be encrypted and thus cannot be read by another NT installation. In combination with standard and very much safe password on the system itself this possibility provides the safety of selected by you important data for the majority of applications.

Security
NTFS contains a lot of means for differentiation of the objects rights, it is supposed to be the most perfect file system from all nowadays existing. In theory it is undoubtedly so, but in current implementations unfortunately the rights system is far enough from the ideal and is a hard but not always logical set of the characteristics. The rights assigned to any object and unambiguously by the system itself. The large variations and additions of the rights were carried out already several times and at the creation of Windows 2000 they came to the rational enough set.

NTFS file system rights are close connected with the system itself, and that means they are not obligatory to be kept by another system if it is given physical access to the disk. For preventing physical access in Windows2000 (NT5) the standard possibility was taken (about this see below). The rights system in its current condition is rather complex and I doubt that I can tell something interesting and useful to the readers. If you are interested in this topic, you can find a lot of books on the NT network architecture where it is described more than in detail.

The description of file system constitution can be completed, it is necessary to describe only some just practical or original things.

Compression
Files on the NTFS volume have one rather useful attribute - "compressed". NTFS has built - in support of disk compression. Earlier Stacker or DoubleSpace was used for this purpose. Any file or directory in the individual order can be stored on the disk in the compressed form and this process is completely clear for applications. The file compression has very much high speed and only one large negative property - huge virtual fragmentation of compressed files which however does not bother anybody. The compression is carried out by blocks of 16 clusters and uses so-called " virtual clusters ". This decision is extremely flexible and permit to achieve interesting effects - for example a half of file can be compressed and a half is not. It is achieved because the information storage about compression rate of the defined fragments is very similar to usual file fragmentation: for example the typical record of physical layout for real, not compressed file:

Journalising
NTFS is a fail-safe system which can correct itself at practically any real failure. Any modern file system is based on such concept as transaction - the action made wholly and correct or not made at all. NTFS just doesn't have intermediate (erratic or incorrect) conditions - the data variation quantum cannot be divided on before failure or after it bringing breakups and muddle - it is either accomplished or cancelled.

[Athens]

Originally Posted by Maflynn

Even MS is moving away from fat32, so I don't think apple would even consider embracing it. Also I think that HFS+ is already intergrated into the architecture of the OS, there's little reason to change it. Don't forget Apple is not creating a new OS for the hardware, they've been keeping parallel copies in development that means all pieces should be the same - even the file system.

For the record, I've not had issues with NTFS, does it fragment a file right of the bat, I don't know. Do I care, no. It works. In my job it matters not that my spreadsheet is fragmented over 50 times, just that its there is the important thing.

Mike

A reason why iPods setup for Windows uses Fat32, it works on OS X, Windows, and Unix.

[Targon]

Hey Athens man, thanks for providing this info on NTFS. After my surprised findings i was hunting info from PC wizards that would try to explain my findings to me, (of course no-one had a clue as usual). The data you provided is very explanatory, so again thanks ;-)

This info pretty much reflects my findings, however, i noticed fragmentation on uncompressed files instantly on the first copy. Of course it got worse with more files but the fragmentation was severe way before the disk was any where near full.

As with you i don't believe i have had much of an issue with corrupt files with NTFS, but i also have not had any issues with file corruption on HFS/HFS+ over the years. Perhaps this is due to my dedication to regular FS maintenance?? With corrupt files Im not convinced this is purely the fault of the HFS+ FS. Of course observations from me seem to think this the fault is subject to the application. I have noticed some Audio Apps like Pro Tools and Logic frequently cause ALOT of users huge problems with file corruption, or so called corrupting preferences. Yet other apps like Cubase SX don't really have too many reports of files getting corrupted. This again is only an observed assumption or guessing, for all i know some of these situations may have been due to other factors such as files saved on Firewire drives which we know some Firmwares and OS X updates have been known to corrupt files.

Funny this thread should show up. Ill post a topic shortly about a situation i had with a Fat32 formatted USB Flash disk which a file copy operation to a 10.3.4 machine killed it.

[Athens]

Originally Posted by Targon

Hey Athens man, thanks for providing this info on NTFS. After my surprised findings i was hunting info from PC wizards that would try to explain my findings to me, (of course no-one had a clue as usual). The data you provided is very explanatory, so again thanks ;-)

This info pretty much reflects my findings, however, i noticed fragmentation on uncompressed files instantly on the first copy. Of course it got worse with more files but the fragmentation was severe way before the disk was any where near full.

As with you i don't believe i have had much of an issue with corrupt files with NTFS, but i also have not had any issues with file corruption on HFS/HFS+ over the years. Perhaps this is due to my dedication to regular FS maintenance?? With corrupt files Im not convinced this is purely the fault of the HFS+ FS. Of course observations from me seem to think this the fault is subject to the application. I have noticed some Audio Apps like Pro Tools and Logic frequently cause ALOT of users huge problems with file corruption, or so called corrupting preferences. Yet other apps like Cubase SX don't really have too many reports of files getting corrupted. This again is only an observed assumption or guessing, for all i know some of these situations may have been due to other factors such as files saved on Firewire drives which we know some Firmwares and OS X updates have been known to corrupt files.

Funny this thread should show up. Ill post a topic shortly about a situation i had with a Fat32 formatted USB Flash disk which a file copy operation to a 10.3.4 machine killed it.

No problems I spend the same amount of time on both Windows and PC. I have had one issue of a corrupt hard drive with HFS+ on OS X, lots under OS 9. Since I have been OS 9 free I haven't so my guess it was more a OS 9 issue. But I have NEVER had a single corrution on NTFS which is what makes me think the file system is very strong. On the other hand I have lost the registry a few times forcing me to reinstall so while NTFS is strong, Windows have other issues like the Registry that keeps it as a perfect package.

File corruption itself is a different issue with Macs and Windows. Files are very different. Mac files are really forks and window files are just a file lol. Mac files are just more complicated and easier to corrupt because of that.

[ghporter]

Originally Posted by tooki

ext2, ext3, ReiserFS... Linux has a smattering of great filesystems.

That said, if Windows can manage to work on FAT32, it should be able to run on HFS+ magnificently. Windows could probably boot off of a toad if you wired it up.

tooki

It would have to be an exceptional toad-exceptionally large at least!

[Athens]

Originally Posted by ghporter

It would have to be an exceptional toad-exceptionally large at least!

Oh thats soooo easy, take a Windows Box with CD inside, out on your best boot and BOOT it off the toad, just be very careful not to hurt the toad I think the same can be done with any other OS, but there is no fun or desire to kick them

[ghporter]

Originally Posted by OreoCookie

Well, out of the box Windows does not support any Linux filesystem, you'd have to install drivers for each. And then you can get a HFS+ driver anyway. The problem is clearly Microsoft again: it has no intention of supporting some common denominator. Also they are trying to collect license fees for devices using the FATxx filesystem. In other words, mp3 players and memory cards as well as digital cameras.

<snip>

Technically I see many filesystems which could serve as the basis for a Mac, ReiserFS, XFS, FreeBSD's FFS (which is pretty much on par with the other two). I'm sure if MS supported a common denominator, so would OS X.

I'd quote Peter from Family Guy about how successful I'd like to see MS in getting fees for the FATxx filesystems, but this is supposed to be a family friendly forum. I see a need for a grassroots effort to free non-Mac, Intel (and AMD) based systems from MoneySoft's greeed. (Me cynical? Naaaah. Just disgusted, thank you very much.)

[workerbee]

Originally Posted by Athens

Oh thats soooo easy, take a Windows Box with CD inside, out on your best boot and BOOT it off the toad, just be very careful not to hurt the toad I think the same can be done with any other OS, but there is no fun or desire to kick them

As if those poor toads' life wasn't hard enough.

[JLL]

Originally Posted by Athens

Can OS X be installed on Fat32? I know it can read it but to run off it, I havent tried that yet. If so I wonder if you could daul boot OX X and Windows XP from the same hard drive partition.

That would be quite a mess of files and folders if it was possible.

[ghporter]

Windows™ XP® Toad Edition comes complete with toad and CD. Not responsible for any warts in your system.

[Lew]

Originally Posted by Athens

But I have NEVER had a single corrution on NTFS.

You've never had it suddenly decide that a folder is a file? That's a fun one when it does it to CWindows, although thankfully chkdsk is usually able to fix the problem. We also had it do the same thing to the licence folder for eTrust Antivirus on half the machines where I work a while back. That was a fun one to fix, believe me.

[ghporter]

Lew, you have been party to an exceptional set of events. NTFS almost always manages to not only properly keep track of what's what, it also almost always keeps proper track of who owns and has what rights to what as well. I've never seen any NTFS corruption on a machine I've been involved with.

Further, if chkdsk is what you used to fix the problem, it sounds more like you had a disk problem than a filesystem problem. To have this sort of thing happen to multiple computers in a relatively short space of time sounds like a power problem that allowed the disks to become somewhat corrupted, rather than a problem with the OS or filesystem. (And I'm going to guess these machines were running Win2K instead of XP, which features a new and more robust version of NTFS.)

[OreoCookie]

I had no problems with NTFS to date. With OS X, all filesystem-related problems stemmed from faulty harddrives. Newer versions of NTFS extended its journaling capabilities (as they were not as strong as that of other filesystems).

[tooki]

I also am of the opinion that NTFS is a good filesystem. It doesn't seem to get corrupted much. (The operating system that is normally installed onto the NTFS disk, on the other hand, can.) HFS+ has always been a reliable and stable filesystem, but journaling took it to another level. Corruption now very seldom happens. HFS+ seems to be far better at preventing fragmentation, and the auto-defragging in OS X helps even more.

tooki

[Tesseract]

NTFS may be "good" but it doesn't support symlinks, which makes it useless for a Unix-like system such as OS X.

[OreoCookie]

Originally Posted by Tesseract

NTFS may be "good" but it doesn't support symlinks, which makes it useless for a Unix-like system such as OS X.

NTFS does support symlinks.

HFS+ is also not really such an up-to-date filesystem. There are more modern alternatives, Reiser4, FreeBSD's FFS (with soft updates) and some others are ahead of HFS+.

Thing is, all these arguments are largely theoretical and the chances that OS X will run on NTFS are worse than a snowball in hell. I'm not sure whether Apple will completely replace HFS+ in the near future (in the course of the next couple of years), but it would make sense to do so and make use of the many man-hours invested in other, more modern and freely available filesystems.

[ghporter]

Aside from a few things it doesn't properly support (though I think it's expandable enough to do so -in a new version, of course), the only thing I don't like about NTFS is the "reserved system space" used for the MFT. It's HUGE on any decent-sized drive. Sure, it overcomes the problems with the FAT concept, but come on! At least with Unix-like file systems it doesn't look like you're getting cheated out of part of your hard drive because of a huge file-like object.

[Tesseract]

Originally Posted by OreoCookie

NTFS does support symlinks.

As long as you only need symlinks to directories.

[OreoCookie]

Originally Posted by Tesseract

As long as you only need symlinks to directories.

Windows uses shortcuts to link files, which work similarly to an alias on the Mac. According to Wikipedia, NTFS supports hard and soft links, although they did not specify things any further. I hardly find this might be a deal breaker. If it hasn't been implemented yet, I'm sure it's not big deal to do so.