Best way to format a drive for both Mac and PC?

#10

It doesn’t really hold true.

If you buy a large enclosed drive (or any drive with reason to be pre-formatted), it will usually be GPT, regardless of FS. If it’s less than 2 Tera and older than a year, it will probably be MBR, regardless of FS.

Neither is an issue on either platform, nor it matters much unless you need large partitions.
Allegedly GPT is less prone to corruption, but that’s in cases that differ from home use.

For home use, unless you have a 3TB drive, you don’t care, it’s just the table to show the system the available mapping to partition.

as for the file system, i’ld go with NTFS but like pointed out, you’ll need something on the Mac to be able to write to it… not so sure how the security is handled on the Mac.

exFAT will work in Lion/Mountain Lion and Vista and on, has no single file 4GB indexing limit, and to my knowledge (other MS having a patent pending on it) has no major drawbacks and is managed natively in both platforms.

Pre-Lion Mac formatted exFAT drives would usually not read in windows (the only surefire way was to use an external software in win I believe), but Lion addressed it.

I don’t have a mac at home, but received multiple exFAT drives from my editor before and had no problems whatsoever using them, and handing him data back on them (and he uses Macs exclusively, whereas I use Linux and Windows exclusively).

Slightly trickier in Linux, but not an issue if you know your way around.

Absolute pain in the arse in more embedded systems (sharing a drive through a NAS or Router), as none of the embedded mini-unix running on those devices, or even the more complex ones (like Syn or QNap’s NAS OS’) have proper exFAT support. In those cases fat is usually more compatible.

Any reasons why nobody pointed out exFAT yet? NTFS wrapped is a pain in the arse.

#11

maybe because it just wasn’t adopted so well and microshaft has a death grip on it…?

#12

Like someone else said, read support is built in but not write. NTFS is probably closed-source, so any implementation of write is a reversed-engineered hack, which would be too risky to add natively since MS doesn’t have to document changes to the FS. just a guess.

#13

just a note that you should be careful about what you put on the NTFS system since file permissions, ACLs and Mac-specific things might not work correctly. Documents would be okay, probably, but avoid anything like applications, Mac Postscript fonts or system-specific items like that.

#14

What you’re asking for is exFAT. A better solution in a studio environment would be to use a file server or NAS and let the workstations share data through that. Then the filesystem wouldn’t matter to the clients because the data would be accessed through networking protocols (SMB, NFS, AFP, whatever).

#15

Huh?
Sorry, but Lion, Mountain Lion, and any MS from vista and on supports it, and MS has an even tighter and fiercer grip on NTFS, while they are desperate to see exFAT picking up and loosened constraints considerably.
That makes it both MORE adopted AND not as tightly gripped by the balls.

In fact, take note of how NTFS isn’t natively supported in macs, while exFAT is.

So, still don’t see why NTFS is being recommended over exFAT other than oversight, or people not being aware of it being so convenient these days.

#16

i’m not aware of it being as convenient for mac users… but good to know.

#17

It’s listed under the format options for Disk Utility so it seems like a good option. I just haven’t used it before.

#18

Well, then the thread served a purpose.
Maybe time for some testing and writing an article of your own about it Beige :slight_smile:

I know I’ve moved teras worth of data on drives (even chained JBODs that got picked up correctly on both) with it coming from my editor, but all my experience is windows side, the Mac counterpart was coming from someone else.

#19

I’m curious to know how it performs as well and if there are any gotchas. :thumbsup:

#20

For a desktop drive kind of scenario, I didn’t notice any great difference from my e-SATA or my NAS (which is surprisingly fast). On large files sustained for a while they all cap more or less the same at what the controller’s buffer can handle from the disk, so anywhere between 70 and 100+spare change MBps.

I haven’t tried the many small files scenario, or the office and data management scenarios as those just don’t exist much in my IT life (my many small files scenarios will usually be capped by git a lot sooner than the drives or my bandwidth can struggle).

For home, or any single drive, use I’d be surprised to see any modern file system even just edging past another.
In a corporate environment and when it comes to reliability I’m sure things would differ, but at that point any sane person leaves it to the storage system requirements to guide those choices, and they are very unlikely to be any sort of fat or ntfs if you use a unix system.

#21

Here a nice article about this;

http://externaldisk.co.uk/article/2012/05/14/format-my-drive-for-mac-and-windows.html

The guy say that while exFAT is nice, it is slower and use more memory than FAT32.

The guy recommand to stick with fat32 but I really cannot. I got a lot of big ZIP and MOV files to backup that are bigger than 4gb.

Time capsule will not work with NTFS…

#22

Maybe the best way for me would be to format the disk in 2 partitions, one 500gb for my current (windows) projects, then the rest in OS X Extended Journaled.

That way I can still use the disk on both system and use it for time capsule.

I presume windows will just ignore the Extended Journaled partition?

#23

Thats exactly what I used to do and it worked fine, though after this Ill probably just stick with exfat, I was always under the impression it still had the 4 gig limit and just allowed for drives over 2 tb

#24

I doubt the claims of noticeably inferior performance, but regardless, I can’t see why you shouldn’t do what you propose at least to have time capsule running.
You were already willing to format the Drive anyway, just do it and see if it works, and report back IMO.

#25

so I pitched the exFAT article to the Ars editors and they are interested, so we should have something on the site in the couple months, since I want it to be a “month with exFAT” type article so any problems that could creep up would probably show up in that time.

#26

I demand credit and royalties!

#27

lol… well, i too would be interested in the read. can you (when complete) make it sharable for us here?

#28

I challenge you to get the word Fragapane into the article. Google tells me it means strawberry bread in latin if that helps.

#29

Having had a look at that article, and other more reputable sources, I would ignore it wholesale.
He’s just spewing some common misconceptions and offering nothing to back them up.

exFAT is agreed upon to be safer, more efficient, and way faster in almost every case than FAT32, with the only exception of small volumes with many small equally sized files written sequentially, which is unlikely to interest you.

Space allocation and deletion (since exFAT offers a proper file map) in example is something retardedly faster, dozens to hundred times faster for the seek.

As it was born for flash drives and all it misses a lot of security features and the such (only has access control per file, no encryption etc.), but for an external device across platforms that’s fine. Also, it’s not like FAT32 has ANY of those anyway, it’s a very dated, very horrible file system that was well behind the curve only shortly after it was released, as most of DOS was anyway, which had the one and only redeeming quality at the times of being cheap.