Slashdot Mirror
Sharing a Firewire Drive Between Mac and Linux?
jhealy1024 asks: "I was getting short of disk space on my iBook, so I got an external 100GB FireWire drive to expand my storage space. It works like a charm, and so my storage problems are relieved -- for now. Then I realized that my Linux server has several IEEE 1394 ports on it -- maybe I could use the drive to back up files from my Linux server as well! Unfortunately, after an afternoon of frustration, I haven't been able to do it. The problem seems to be that there are no (fully working) formats that both the Linux box and the Mac can use. HFS+ and UFS are supported by both machines, but write support on the Linux side is reportedly still in beta for both. I don't feel that I can trust it yet for backing up files. I've tried UDF, but the versions aren't compatible (Linux likes 2+, and OSX only goes to 1.5). Not to mention, Mac OS doesn't seem to like a whole block device formatted as UDF (mmm... kernel panic). The closest I got was by using FAT32 as the partition type, which does work on both machines. Unfortunately, the max file size is 4GB, which won't cut it if I use the Mac for DVD mastering or DV editing (20 minutes of video == 4+GB). I know I could just partition the drive, but I'd really just like to share files on one device (especially things like MP3s). Has anyone found a good way to share physical devices between Mac OS X and Linux?"
HFS+ support for Linux is almost non-existant. There are tools to do it, but they're kludgy. HFS (no plus) is supported, IIRC. Your best bet may be to have a separate HFS partition and use it as a temporary storage disk--mount it in OS X, copy files to it, mount it in Linux, get the files off, copy any Linux files you need in OS X to it, etc.
- Standard.
- Designed for large data sets (1 GB).
- Designed for large file transfers.
That said, UDF is usually used in DVDs and I don't know if and how a firewire drive can be formatted in UDF, but it might be worthwhile to check it out.i'm in the same boat, but with a mac & win98/2000 box.... anyone have any idea how well an OS X 10.2 box plays with a NTFS(+?) (i think) filesystem hard drive? i have yet to play w/the firewire drive and windows, as i don't want windows trying to format everything on my 100 gig drive. i'd rather not have to buy any "read mac formats on pc!" software...
any help/suggestions?
moox. for a new generation.
Not the best solution but a solution never the less would be two partitions on the disk. One parition set up as HFS+ for the DVD mastering since you require support for large files and another as a FAT32 for sharing of files between the Mac and Linux systems.
Since you didn't mention DVD mastering on the Linux box I'll assume you don't do that. HFS+ read support is support under linux (write support has a warning of being dangerous the last time I compiled a kernel). If required you could still back up the large files from the DVD mastering partition to the Linux machine - you just couldn't safely write them back (you could use something like sftp, or rsync to copy them over an network connection if required later on).
It's been a while since I submitted this article, so I'll bring you guys up to speed on my other attempts:
While I appreciate the two-partition suggestions, they're not quite what I'm looking for, as I don't want to split the disk in half for the two different machines. The "transfer partition" (a small partition in HFS that both machines can read) idea is a good one, but when I get to that point it's easier to just network the machines together and copy the files rather than waste the disk space.
On that front, I've tried NFS and Samba between the linux box and the ibook, without much success. I suspect it may have to do with large file support on the linux side.
The NFS mount works okay, but then randomly craps out (I get read errors) on large files. I've tried tuning the NFS connection params (different version numbers, TCP/UDP, buffer sizes) without much luck.
With Samba, I'm smacking into the large file size limit on linux. I wanted to try an SMB mount from the linux to the ibook. The ibook seems to be exporting the full sizes on the files, but the linux size can't see files over 2GB. I've recompiled Samba on both, but that didn't help. Therefore, I think I need to patch my kernel for large file support in SMBfs and try again.
I just bought Jaguar, so I'm hoping that I might get a little help in the new release. Also, I haven't tried AFS yet... =)
Mac OS X should be able to see all partition types that FeeBSD can see. Linux too.
I was thinking that, too. I have no experience OS X, of course, but everybody keeps talking about how it's a *nix. It would be pretty lame if something as dumb as support for open file system formats was the thing that killed that notion.
Under capitalism man exploits man. Under communism it's the other way around.
In spite of the hasty moderation, this is not a bad suggestion at all. Captain Pedantic was suggesting to use tar in the mode which writes directly to the disk without any filesystem. Tar has this ability primarily so that it can write to tapes, which don't have filesystems, but it can be used with any device. Since tar uses the same format on both OSes (or at least GNU tar does, which is available for both), the data should be available to both. Plus, tar works well with big files. The big drawback is that this will only work for backing up and restoring; you can't use the files directly from the disk with any program other than tar.
But my grandest creation, as history will tell,
Was Firefrorefiddle, the Fiend of the Fell.
Why not just format the drive as HFS (no plus).
Does MacOSX still support it, or did Apple drop support of it?
The last time I used HFS with Linux, it was fine. Back then, there was NO HFS+ support in Linux, but apparently there is some now.
Another solution might be fat32... does MacOS have any support for it? I used to be able to use fat32 formatted zip drives way back when in classic MacOS. Unfortuantly, I don't have a mac anymore to test any of these things with.
One approach: Use tar to create an archive in the raw partition. This is what tar was originally invented to do, though with tape device files, rather than disk device files. I suppose that's good for archiving stuff, but not much else. Do you mind copying your video files to internal disk before working on them?
Another approach: create a partition the same size as the file you want to put on the disk... Well, that could get weird.
Too strange, too complicated? Probably. Just brainstorming here.
Mac OS X should be able to see all partition types that FeeBSD can see. Linux too.
Not entirely true; Mac OS X has a FreeBSD compatibility layer, but is not based on the FreeBSD kernel. It uses a Mach Microkernel, similar to GNU HURD. Although they can technically port any filesystem drivers from FreeBSD over to OS X, this is not true for Linux filesystem drivers- Since Linux is covered under the GPL, filesystem drivers in Linux are also covered. Hence, without GPL'ing OS X (at least their entire Kernel), they can't pull anything from Linux.
So, you won't likely see anything like reiserfs in OS X anytime soon.
Does anyone know if it's easy / possible to create a third-party filesystem driver for OS X? I don't like Apple stuff, so I don't know much about that part of OS X internals. Do they have a Loadable Kernel Module interface? Anything like that?
get 0wned. irc.w30wnzj00.com
Rob, you listening? What purpose do IMPs serve? Aside from destroying the credibility of the moderation system, that is.
I do want to disagree with Captain Pendantic (hey, I'm sometimes known as Lord of the Nitpicks, I guess we haven't met) on one point. The moderation system is not a system of rewards and punishments. It's a filtering system. Of course, in this case, it failed as a filtering system, by removing extremely relevent comments from the discussion.
I'm dumping IRIX, Unicos, QNX and VMS!
"Flyin' in just a sweet place,
Never been known to fail..."
Somebody doesn't know what 'microkernel' means, nor understand the GPL.
First, microkernels are all about modules, in fact, modularized drivers are the whole point of having a microkernel. So, yes, in theory a third party could write drivers. However, as you have already pointed out, at least indirectly, the OS X kernel is a closed Mach variant, so who really knows if it's possible to create driver modules for third party file systems? It seems like it would be a stupid thing to prevent, but I'm sure an MBA could make a reasonable-sounding case for it.
Also, while we're on the subject, It's the Mach kernel which is BSD compatible, since at least Mach3. That isn't something special that Apple added.
Now as for the GPL, they could use the GPL code only in the module, which would mean that only the module would be subject to the GPL, or they could write their own code which interfaces with the APIs (or whatever they are called) for reiser/ext3/whatever and none of their code would be subject to the GPL.
Don't buy the FUD. The GPL is not nearly as viral as Microsoft would have you believe.
Under capitalism man exploits man. Under communism it's the other way around.
Actually, last I read, under the GPL, modules which are inserted into running code count as derivative works. The linux kernel makes a special exception saying that binary-only modules are allowed. In any case, it's a sticky subject, and they'd need to at least secure permission for this specific use of the code.
My question about whether or not third-party modules could be created was meant as "has apple made the interface for this an open specification?".. That is, I know how microkernels work, but I don't know how feasible it is for mac os X. Do they include the right header files and provide an API for third-party (especially open-source-- They can very possibly put some sticky licensing into a developer license for the API) modules?
As for the "viral" nature of the GPL, It's so called because a large number of open-source licenses allow their code to be included into GPL'd code, but the GPL does not allow that same liberty.
get 0wned. irc.w30wnzj00.com