Slashdot Mirror
Best Format For OS X and Linux HDD?
dogmatixpsych writes "I work in a neuroimaging laboratory. We mainly use OS X but we have computers running Linux and we have colleagues using Linux. Some of the work we do with Magnetic Resonance Images produces files that are upwards of 80GB. Due to HIPAA constraints, IT differences between departments, and the size of files we create, storage on local and portable media is the best option for transporting images between laboratories. What disk file system do Slashdot readers recommend for our external HDDs so that we can readily read and write to them using OS X and Linux? My default is to use HFS+ without journaling but I'm looking to see if there are better suggestions that are reliable, fast, and allow read/write access in OS X and Linux."
UFS would be the best option. Linux supports it with -rw since Kernel 2.6.30 (afaik) and OS X mounts UFS natively.
I have a similar problem, albeit on a smaller scale. I use unjournalled HFS+.
However, the problem is that HFS+ being a proper unix filesystem remembers UIDs and GIDs which are usually inappropriate when the disk is moved.
Is there any good way to get Linux to mount the filesystem and give every file the same UID and GID, like for non unix filesystems?
SJW n. One who posts facts.
NTFS :)
My default is to use HFS+ without journaling but I'm looking to see if there are better suggestions that are reliable, fast, and allow read/write access in OS X and Linux.
So I see you're the "if it ain't broke fix it anyway" type.
Ask Slashdot: Where bad ideas meet poor googling skills.
You will want to use vanilla FAT32 but then beef up the data with par2 and/or sfv files for error recovery and checksumming respectively.
FAT32 isn't reliable as anything but a lowest common denominator between platforms, anything else will give you headaches especially if you need to share the drives outside your local ecosystem.
QuickPAR and QuickSFV are the Windows utilities I've used, there are probably versions available on all platforms.
By "HIPAA Constraints" I assume you mean the privacy rule. I would think that this rule would prevent you from using sneakernet to transmit files. Unless you're encrypting your portable disks, and somehow it doesn't sound like you are.
Fun reading:
http://www.computerworld.com/s/article/9141172/Health_Net_says_1.5M_medical_records_lost_in_data_breach
More like "I don't know if it's broke. I could be doing something so wrong it could end up on The Daily WTF. If what I'm doing is broke, could you help me fix it?"
FAT32 has a file limit size of 4GB.
He needs 20 times that!
How the fuck is he supposed to store 80 GB files on a filesystem that maxes out at 4 GB?
NTFS or any other FUSE (MacFUSE) file system. However in a heterogeneous environment NTFS has the bonus of native Windows support.
There is NTFS-3G for Linux and Mac OS X
There is also an EXT2 Fuse FS (for Mac OS), and probably many other options.
Having said that, I have never had a problem with Linux's HFS+ write support.
Mac OS and Linux both have support for NTFS through NTFS-3G. Mac OS has support for ext2 through fuse-ext2.
[insert witty comment here]
I have a similar scenario and I think HFS+ unjournaled is best for your scenario. FAT32 is even worse. You are fortunate not to have to support windows. Ideally I would use NFS and file sharing instead of external disks. But shipping a disk is always better than transferring large amounts of data over the net.
Another option is to install MacFUSE and then mount other file systems. This is what I do when NTFS is required. For my Linux system I love ext4, if you need an older file system use XFS, ext3 is stable but really slow for large data files.
It sucks, but NTFS might just be the best option. OSX and linux both have had stable enough support for years. The main plusses over FAT32 are journaling and support for files > 4GB. Using UFS is dangerous (or at least has been until very recently) because there are so many different variants of it (solaris, BSD, osx, etc.) that linux support is notoriously troublesome. An extra plus of NTFS is you can use it easily on windows machines as well.
I would have recommended ReiserFS, but the data might get buried somewhere and the system would not remember where it was....
Take Nobody's Word For It.
If you are only moving files from one system to another, and do not need to edit them on the portable drives, skip the filesystem and just use tar. Tar will happily write to and read from raw block devices... In fact, that is exactly what it was designed to do. A side benefit of this approach is that you won't lose any drive capacity to filesystem overhead.
Ask Slashdot: Where bad ideas meet poor googling skills.
Here's a commercial $39.95 implementation of ext2/3/4 for MacOS. No idea if it's actually any good. I'd really like to hear if someone here has tried it, because I might like to use it for a shared /home between Linux and MacOS if it would work. I tried hfs+ (or it was it just hfs?) without journaling, and the dang thing needs to be fsck'd nearly every time I booted the alternate OS, which wastes a lot of time. Particularly, when shutting down Linux it's unmounted cleanly (such that Linux is happy if I just boot back into Linux again), but MacOS is still not happy and does the fsck in the background for 15 minutes or so before I can access it again. Sometimes it fails too, and has to be done manually from Disk Utility. Quite annoying.
You're storing it in the wrong format - there are all sorts of tools to convert to Analyse or DICOM format, which give you a managable frame-by-frame set of images rather than one huge one. Most tools to manipulate MRI data expect DICOM or Analyse anyhow (BrainVoyager, NISTools, etc).
If you really want to keep it all safe, use tarfiles to hold structured data, although if you do that you've made it big again.
Removable media are a daft long-term storage - use ad-hoc removable media solutions (or more ideally, scp) to move the data.
For every problem, there is at least one solution that is simple, neat, and wrong.
I'd say the "best format" needs journaling absolutely, and preferably also extended attributes which work consistently between the two OS's, hardlinks and symlinks working consistently, long filenames, case sensitive, separate metadata for creation time and modification time, suitability to be used on a USB flash drive as well as a hard disk, and ability to mount it in Windows too. Haven't found any such mythical beast yet. If somebody would just finish the journaling support for Linux HFS+....
No, seriously, who cares? This is a process designed to save files that are then transferred through SneakerNet. While moderately large, at 80gb, they're not huge by modern standards. If you have a current solution that works, stick with it.
If, however, there are other constraints that are affecting you - transfer speed, decades-long retention on local media, security, etc, then by all means let us know. Until then, to use the obligatory car analogy, its as if you've said:
Due to the distance between my house and work, I currently use an automobile to go between the two locations and to perform various other services. Currently I use a Honda Accord. What would you suggest?
You're special forces then? That's great! I just love your olympics!
Just tunnel NFS over SSH. I can't imagine how secure it would be to sneakernet any files around the office. If you need to encrypt the data at rest then either encrypt on the client or leverage an encrypted filesystem of a Decru type appliance.
If you are carrying these things around, I would think setting them up with TrueCrypt (works on OSX and linux) or other full disk encryption program would be a Good Idea (TM). It would be bad to have sensitive data get left somewhere. This way you would just be out the cost of hardware (assuming the data is backed-up). I would guess that HIPAA would want you to do what you can to protect that from happening.
Best of all, it has a proven track record: http://www.theregister.co.uk/2010/06/28/brazil_banker_crypto_lock_out/
OS X UFS has a very unfortunate limit as it doesn't support files over 4 GB. Or, there was no chance, I would format everything (especially USB) as UFS.
Lack of commercial quality disk tools like Disk Warrior if a true catastrophe happens is a problem too. Of course, fsck can do good things but after a true catastrophic filesystem issue, diskwarrior is a must. That was one of the things Professional Mac community had hard time explaining ZFS community.
As Apple was truly wise to completely document it down to a point you can even write a full feature defragmenter (iDefrag), HFS+ without journaling seems to be the best option. I am in video business and I have seen it deal with files way beyond 80GB without any issues. In fact, lots of OS X users who images their drives see it everyday too.
I don't know why journaling is not implemented, it is open and documented too. If a bit hassle happens, it sure deserves it since he deals with external drives which are just fit to journaling purposes.
Most of files they produce involves an actual patient, sometimes in critical condition stay in something like a grave for hour sometimes.
If one of issues with filesystem, that archaic junk which should have never been released happens, it will be nightmare to restore the data while it is easy on HFS+ Journaled or even NTFS.
I own a Symbian phone and trust me on that, if there was a $50 utility just to get rid of FAT32(!) junk risking my data on memory card, I would happily buy it.
I heard it is almost a standard procedure to use iPods in X-Ray community for the x-ray format images and that is why there are several OS X Utilities supporting it.
I guess the first reason was the gigantic (for that time) storage size of the iPod and you can also use it for music.
Really, you need a gigabit network and transfer files over it using AFP and/or NFS and/or SMB. First of all HIPAA requires you to encrypt your hard drives which most researchers won't do (it's too difficult). Then you also got the problem what happens if the researchers (or somebody else) leaves with the data.
Solaris and by extension Nexenta have really good solutions for this. You can DIY a 40TB RAIDZ2 system for well under $18,000. If you use desktop SATA drives (which I wouldn't recommend but ZFS keeps it safe) for your data you can press that cost to $10 or $12k.
I work in the same environment as you (neuroimaging, large datasets), feel free to contact me privately for more info.
Custom electronics and digital signage for your business: www.evcircuits.com
As Apple didn't want to bother with "OS X deleted my NTFS drive" people, they support NTFS as read only by default. "NTFS-3G" and other utilities can of course read/write but it doesn't change the true reason for NTFS being unreliable to support: It is _not_ documented.
HFS+ on the other hand is completely documented. Apple wins on this case because of openness and the fact that, their true discipline in making things backwards/forwards compatible with complete documentation.
Nobody had to/has to reverse engineer anything, the source code of HFS+ is right at opensource.apple.com
I would say - 3,5" if it's a desktop or 2,5" if it's a notebook
You should consider creating a samba share. If you don't have a server a NAS appliance or a el heapo old PC would handle the job very well.
RAID array and NFS, a Lustre, etc depending on need, but a network share! ...and if you need more encryption and even admins cant have access to data, have your users store true-crypt drives on the network. Sneakernet is, in the end, far more insecure!
"goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
I'm using a USB Disk formatted under linux with UDF (yep, it's not limited to DVDs, there is a profile for hard disks). It can be used without problems under OSX (even Snow Leopard)
Marquise
-- I need a new sig.
XFS handles large files VERY well, but I'm not sure of OSX support. Darwin is just a modified BSD kernel so it COULD have support. Question is whether the iCzar decided to build it in . . .
tar --posix --noxattrs --mode 644 cvf /dev/... honking-big-file.img
Handles large files well, doesn't respect UNIX permissions (which are problematic for removable drives) and is freely installable on Linux and Mac using NTFS3G and FUSE or MacFUSE. A lo
aka Matthew at SlashNOT/!
who will wooosh the woooshers?
A simple NAS enclosure or NAS device might be what you are looking for. You can get a single drive NAS enclosure, and add a drive, that you can carry around just like a regular portable drive. You can move it between networks and use any connection method the NAS device happens to implement (SMB, FTP, NFS, etc). Some even let you optionally connect it directly via USB or eSATA to access the file system directly, and some may have encryption or other security features as well.
Of course, check to make sure you have permission and that connecting things to your network does not violate any policies. If connecting a network device directly to the your network is not permitted then perhaps you can add a second, dedicated, network card to the computers.
Treat the disk as if it were a tape, and use the GNU version of cpio.
You can install GNU cpio via macports on your Macs, and people with Linux should find it either already installed or available in their distribution's package system.
You need to use the GNU cpio instead of the BSD cpio that ships with OS X because there are incompatibilities between the two, and I was unable to find a set of settings that would make them compatible. (There are settings that should, but they did not work, so there's a bug in one or the other--or both. However, after a few minutes experimenting it occurred to me to just grab GNU cpio from macports and use it on both ends, so I never pursued tracking down the incompatibility)
Note that you can also get GNU cpio for Windows.
I do my fair share of transferring large neuroimaging datasets around from time to time, although I don't do it regularly. If you want to use hard drives that aren't connected to anything in transit, then I have to agree with whoever suggested doing it without a filesystem. I've always found that to be the easiest way to get around filesystem (and sometimes operating system) idiosyncrasies, whether you're writing to a DVD or a hard drive or whatever. If you can (de)serialize your data easily (using tar), then a filesystem does almost nothing useful for you, it just gets in your way.
I certainly won't agree with the respondent who suggested that you change your workflow (and perhaps your choice of tools) to use smaller files. If those are your files, those are your files. Perhaps I'd do it differently, but that's my problem, not yours.
I have a similar problem with backups in my paper less medical practice - I always need a working system off-site for emergency replacement, and here in rural Australia doing it via Internet is impossible due to lack of networking infrastructure and ridiculous bandwidth costs
I use a QNAP NAS (TS659). They also come as tiny handy cubes with 2.5" disks instead of the 3.5"
That makes the question of the file system irrelevant, since it communicates with just about any operating system through standard protocols (eg NFS, AFP, SMB). Internally they use ext3 or ext4 file system depending on user preferences. Whenever I want to transfer files, I simply take one disk drawer out and simply shove it into the QNAP at the second location, where it will immediately start to replicate it. I use a spare disk for the original system, where the RAID1 configuration will immediately rebuild it, to be ready when I come again for the disk next day.
Horst
Ok everybody's occupied with surreal suggestions, but anyway:
*UDF* is quite awesome as a on disk format for LinuxOSX data exchange, because it has a file size limit around 128TB, supports all the posix permissions, hard and soft links and whatnots. There is a nice whitepaper summing it all up:
http://www.13thmonkey.org/documentation/UDF/UDF_whitepaper.pdf
If you want to use UDF on a hard disk, prepare it under linux: /dev/sdb (that's right, UDF takes the whole disk, now partitions)
1) Install uddftools
2) wipe the first few blocks of the hard disk, i.e. dd if=/dev/zero of=/dev/sdb bs=1k count=100
3) create the file system : mkudffs --media-type=hd --utf8
If you plug this into OSX, the drive will show up as "LinuxUDF". I am using this setup for years to move data between linux and OSX machines.
Marquise
-- I need a new sig.
The best cross-platform (Linux+MacOS) filesystem is NFS, wh-- stop hitting me, I DID read the whole question. Ok? So, as I was about to say, use NFS. When the techno-ignorant HIPAA people watch what you're doing, just send 80gig of /dev/random (bonus: it looks encrypted, the HIPAA guys will love that) to the removable drive, and when you're coping off that drive, send to /dev/null. Meanwhile, as the drive's contents are going to your lame software-emulated null device, also be reading the file off the ethernet via NFS. Problem solved.
But in all seriousness, the guy who said "tar" was right. I wouldn't have thought of that. Brilliant.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Give the man a cigar. I was struggling through all the other suggestions, every single one of them involving unacceptably horrible tradeoffs, and finally get to this post, the only idea that is not just mind numbingly brain dead. I don't even use OSX any more (finally cured that brain disease), and I'm gonna check this out.
journalling is there to help provide a safe guard against data loss and corruption. using HFS+ without the journal can be risky - I have experienced problems personally from this - any freeze up, reboot without proper unmounting of the drive, etc and you are in trouble. While I haven't tried NTFS is seems to be the most compatible between OS's, meets your requirements for file size of 80 GB's:
https://secure.wikimedia.org/wikipedia/en/wiki/Comparison_of_file_systems
A FREE driver is required:
https://secure.wikimedia.org/wikipedia/en/wiki/NTFS-3G (this driver seems well tested and stable)
Just curious. Is the 80GB after applying lossless compression to the image set? If not, there's no good reason to store it uncompressed.
As for your question, I agree with those that say to skip the filesystem. Just use tar and a block device.
-Randall
Bit of a pickle, last time I checked OSX doesn't support ext4 while Linux doesn't support ZFS (except with FUSE which I dont reccomend in a produciton environment) which would be my 2 options for performance. I know UFS is in both so that could work but I am curious if OSX can support XFS.
If you could find a driver for ext4 on OSX I would reccomend that: its fast & proven to be quite stable, next best thing would be XFS.
This sig has been distributed under the Creative Commons license.
I see several mentions of using NTFS on OS X but no mention of using a commercial SUPPORTED version that is commonly available - for instance Paragon NTFS 8. I have used v7 and upgraded to v8 and had little to no issues with it. The only problem I've had was with a corrupted volume.
Is this a religious or moral issue - using only FOSS - or am I unaware of significant issues with this product? It would seem to me that a business would be willing to pay a small amount for support on a product.
I have no interest in the product other than being a user of it.
Be Obscure Clearly
There are visual errors in time as well as in space.
We were forced by a customer to use it for a video storage project. Things just
get lost, never to be found again. ext3 w/ data=journal has been bulletproof
with pretty good retention of the last few minutes. So far.
Something to look into.. Allows other file systems to be used with a mac.
http://code.google.com/p/macfuse/
This is a good solution.
I format my USB flash cards with UDF to exchange large files between Mac OS X and Linux (ya' just can't beat sneakernet!).
I've not (yet) been able to get this to work with Windows though. Even though "modern" versions of Windows supposedly support UDF, it seems to be for optical media only.
That is an excellent solution, and arguably the best to the OP's problem printed. UDF works on Windows, OS X, Linux. Even AIX is happy with it and can write to it. So an external drive with this on it should definitely solve the problem.
I always like to think of the profit angle when there is a problem, the silver lining hiding in plain sight with any problem or hassle. Your situation sounds like a great way to go into business for yourself. Walk away with a few other key players, then contract the work for more money-then do it, use the machines you really need, and as long as you are forced into being your own IT department-so what? You are *anyway* according to what you say so you might as well get paid for it. Get mo' money for more responsibility. Not sure how this works with grants, but sounds like the work really needs to be done, and medical stuff....seems like anything medical related today is a license to print money somewhere just under top investment banks.
File systems...seems like all the heavy hitters here are always going on and on about ZFS, best thing since burritos to go in a bag, etc, so is that an option for your macs and the recipients?
As to file sizes..I'm a dumbass on this but can't they be chunked up, like torrent files are chunked up into much smaller sizes? Torrent them to..wherever they need to go to?
FAT32, NTFS, perhaps ZFS...and following up to the HIPAA remars above, I would use TrueCrypt as well.
Nothing to see here but us trolls...move along...
OK, that makes more sense now, I understand.
Here is the wiki page on zfs. Seems possible with some skull sweat and some hoop jumping. Supports file sizes up to 16 exabyte, so that is certainly large enough. Good luck man!
http://en.wikipedia.org/wiki/Zfs
We had almost exactly the same problem. Our fMRI work was done at University of Virginia on a Linux machine. naturally you don't want to tie up a $1500/hour data collection machine doing analysis. Our data was transferred immediately to the Neurological Institute to a multiboot machine. No patient data included at this point, so no HIPPA problems. The receiving box ran Linux initially since the analysis programs from NIH (primarily AFNI) were Linux based. Patient data got added here so HIPPA became an issue. The machine had multiple hard drive bays, all of which were removable, plug-and-play drives made from a kit that provided slide-in rails and a locking mechanism, otherwise were common, commercial drives. Externals would have been easier, but the guy who devised this had a rilly rilly good reason. I remember it was good, but not what it was. Anyway, the machine could boot other OSs, prep the drives, go back to the native Linux HFS+ and transfer/translate to the , it was transferred, the drive removed, packaged, and FedEx'd to the other analysis sites at Virginia Tech, NIH, and U.Va Wise. We were strictly experimental, no direct medical treatment, and so time was not an issue. With OS X being *nix, there's not a lot of reasons to go with one over the other except for convenience when it comes to what your data collection and analysis are running under. Unless yours run fine under OS X, I'd say stick with HFS+, and of course moderate that according to whether you have to share out the data and what those people are running. I wouldn't bother with supporting Windows, as they continually find new problems to have with large files. One comparison test showed no difference in analysis results, but they did have problems with Windows choking on the data files. Their test files were only 1.5 GB. ref: J Med Dent Sci. 2004 Sep;51(3):147-54. Comparison of fMRI data analysis by SPM99 on different operating systems. PMID: 15597820. My experience agreed with their results. As I said we had little call for Macs, so we didn't run enough of that to give a good test of whether it had the same kind of problems. Bottom line, we used what we needed to according to where it was going and what they needed it to be, but for our own use it made no sense to transfer it out of the OS that collection and analysis used, HFS. The system met with the approval of the biophysicist we worked with at U.Va, and he had been a grad student under Peter Fox when the latter developed SPM. OH YEAH: the good reason. If anyone else wanted to work with us, they didn't have to dig too deeply into techie stuff either hardware or software. We could send them a removable-drive kit to install, and send them a drive with bootable Linux, AFNI and data, all plug and play. If that might be useful to you (using externals instead of removables doesn't matter here) that's probably be another vote for HFS.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
You don't need journaling for sneakernet packets. the big blobs of data are ephemeral, and users need to safely eject the drive anyways to ensure that all the data was copied.
Journaling won't fix a file on a disk that was removed before it was completely copied over, it will have parts missing. Safely unmounted devices will also be able to skip fsck checks (up to a certain limit of days, which is configurable on many Unix filesystem, not sure about HFS+)
MacFUSE with the ext2(or ext3) plug-in works pretty well too. Ext3 plug-in would give you that journaling feature that you find so precious.
I'd like to see a new filesystem become the lingua franca of removable/portable media. One that is easy to implement, has an open reference implementation, is flash-friendly, supports optional extended attributes for a few OSes(name based uid/gid mappings for unix would be nice, just like tar), and generally a concise set of features so when I do embedded devel I don't have to write some crazy dancing b+tree code to access it from my bootloader. Btrfs, NILFS2, Ext4, FFS w/ soft updates, etc are all close to what I want but are too tied to their primary OS to be widely supported. UDF was a tremendous failure, it was too geared towards CD-RW and DVD media but mainly it was only weakly supported by Microsoft and Apple. No support at all would be better so a third-party could step in to maintain it, it just kind of bitrotted over at Microsoft and eventually became unusable.
“Common sense is not so common.” — Voltaire
Sorry, a little off topic but this comment hits me every time "our IT department is reluctant to support them" - then you don't have an IT department - you have bunch of amateurs, whatever useless operators! I'm so tired of these - for real IT it doesn't matter what and how many different OS you are running - none is more or less difficult to support than any other! Yes, there are differences, one might be a little easier for some special purpose than some other but overall - they all are just a bunch of programs to run computer systems!
Back to the subject, I have used / recommended HFS+ or, as someone said, shared filesystems over Infiniband or other fast connection. The problem is really HIPAA and other security / secret / whatever rules, regulations and laws - even today the systems don't have much good standard ways to comply - you often have to develop your own and those skills are scare! And with current education getting even more rare - back to the not so good IT!
That's what we use around here. Works quite well. I work with hundreds of gigabytes of MEG data myself.
If you want to know which filesystem would perform the best, you might try just benchmarking them all with the Phoronix Test Suite. (I haven't tried it myself, but I read Phoronix' news, and there's all kind of pretty graphs.)
Depending on the storage available.
If you prefer to use a Promise with Apple XSan and StorNext you can use Mac, Linux and even Windows on a fiber channel system that can go up to 16 Gb/s.
This kind of storage system can grow up to 2 PB.
More info @:
http://www.apple.com/xsan/features/system.html
Tiago Rosado
IT Manager @ Apple Distributor Portugal
tiagoDOTrosadoATinterlogDOTpt
I have a bunch of hard drives formatted with ReiserFS, with movies on, from ~2002. They are now basically unreadable. Don't use a format pioneered by an axe murderer.
In our lab, in a medical school, developing anatomical atlases, we also got really big files. We had Linux, Mac OS X, and Windows systems to support, and just used FAT32 as the drives came out of the boxes. Images came off the cameras onto a Windows box controlling the stage, and onto these drives.
We also had a Linux file server with LVM running on a RAID5 configuration for long term storage.
Many filesystems support uid= and gid= options in their mount command (including HFS). Just add that to a mount script or set it up in fstab.
OS X does not used fstab. It does leave a copy of fstab containing a message that it is not used, but no information or pointer to what it actually does use.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
What's wrong with FAT32? If you want a filesystem that just works pretty much everywhere it's probably your best bet, and as any ACLs will be ineffective across the disparate systems I don't see why this should present you a problem.
From experience using NTFS on external drives is a PITA and can easily corrupt cross platform, although one poster suggested this. FAT32 will just work...
They're a real IT department - they are very good - they are just under-staffed due to budget constraints (that's one problem with being at a public university). We could let them manage our systems (they do whatever we ask them to do) but we actually wanted to manage our own computers and IT, being reluctant in the first place to add Macs to the infrastructure, is fine with us doing (most of) the managing.
Thanks for the comment. I've tested the HFS+ set up and it seems to be working very well.
You can create the filesystem from OS X, too:
newfs_udf -v /dev/diskX
I'd suggest the man page for newfs_udf for the many options.
I'll second that. There are plenty of free PACS servers available, and you could also ask your MRI vendor for a recommendation (or buy their super expensive version). I've used Osirix before, which I like as a viewer but gets slow when you start building huge libraries of data.
Because I hate when people respond to questions by saying you're asking the wrong question, I'd suggest sticking with HFS+ for file transfers. I don't think you have journalling on Linux, yet, but otherwise Linux HFS+ support is very good. For filling a drive and walking it down the hall, journalling is a little unnecessary anyway. Journalling comes into play more when you're working with the data on a drive. For loading/unloading, journalling will just slow the copy process down a little. If you're worried about the integrity of your copy, do a verify after the copy... journalling won't help you there anyway.
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Whole disk? I've been using partitioned SD cards with UDF for ages now, what's wrong with doing that?
This is awesome! Thank you so much for helping me ditch FAT32 :)
If anyone knows how to convince xp to write to a device like that (via a 3rd party driver or whatever) I'm all ears!
yeah, tried that once, lotsa stuff breaks, mostly windozw-heritage installs:-(
After reading your post, I actually formatted the external drive to UDF 2.51 considering it will be used on Win Vista and OS X latest (SL).
It is a perfect filesystem in theory. In reality, it is either Vista or OS X to blame, it didn't really work as theorized. OS X Disk Utility kept whining, neither OS used the excellent features (store native metadata etc.) offered and lack of "fsck" utility killed it for me.
Now, I know such a excellent option exist without any lack of features and can store native stuff, I got really pissed.
Thanks to "cold war" between both companies, Apple and Microsoft, I don't know who to blame. I went back to old fashion "divide disk to 2, use ntfs and hfs+" method.
BTW; I am not the "MR" guy, I am the guy you replied to.