I share a NAS drive that's hooked up to my D-Link router with PC's and Mac's. It's a Lacie 1TB Ethernet Big Disk that uses the XFS file system.
Will Time Machine work with this?
Will Time Machine work with this?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Will Time Machine work with XFS formatted NAS drive?
- Thread starter HoosierInFL
- Start date
- Sort by reaction score
Read Only
I believe Apple has stated that current with 10.5 there will be only Read access. So writing to any drive, any where, would be difficult.
I believe Apple has stated that current with 10.5 there will be only Read access. So writing to any drive, any where, would be difficult.
surely if leopard connects to a nas it wouldnt need to know the file system? nas software acts as an interpreter and leopard would connect via a protocol such as afp, cifs or ftp??
They are talking about USB/Firewire drives where the Mac would be in control of it and responsible for talking to the filesystem... i quote..
"You can designate just about any HFS+ formatted FireWire or USB drive connected to a Mac as a Time Machine backup drive."
When talking to a NAS, the NAS acts like a translator.
As an example...
If you plug a USB drive formatted as NTFS into a current OS X Machine, The OS can read the drive and you can browse your files. However, you cannot save files to it as OS X cannot write to an NTFS drive.
If you plug the same USB drive into a Windows Box and share it using Samba... OS X can read the drive via the Windows Box and can write to it without a problem. This is because Samba/Windows is acting like an interpreter. This is how NAS works too.
And to give a little more background why TimeMachine will require HFS+: it uses hard-links, specifically the hard links extensions that Apple has added in 10.5. The biggest of these changes is that they support hard-linking a folder, which is not possible in most implementations. This is one of the main ways that TimeMachine saves space as it means that it can have only a single version of each file.
So this limitation is not going away in the near-term.
So this limitation is not going away in the near-term.
I believe Apple has stated that current with 10.5 there will be only Read access. So writing to any drive, any where, would be difficult.
Are you talking about XFS or ZFS? (Not that it really matters....)
Not that you're responding to me, but ... I think the previous poster meant to say that, as previously reported, Leopard uses *multiple* hard linking, which as I understand it, is part of POSIX but is not widely implemented.
Apple has never indicated this publicly, and what they did indicate publicly seems to contradict it.
This picture on myskitch seems to be getting me a lot of use!
HFS, connected physically to a Mac running Leopard on the network (either the one running time machine or another Leopard).
I have a ReadyNAS server so I've been struggling with this as well. One idea I don't see discussed much is to create a SparseImage via Disk Utility and place it on your server share. The disk image is formatted HFS+. I assume (hope?) Time Machine can mount that image and treat it like an HFS+ partition. Shouldn't that work?
This is a bunch of CRAP! I've always had problems writing to a NAS from Mac OS X. The only NAS that would work 100% would be another Mac, cha-CHING! Apple SUCKS! Hello Windows XP! - the platform supported by everything.
Wow. I hope that's joke (the going to Windows part. I understand the overall sentiment regarding NAS issues, as I have the same problem)....
If not, See you in 6 months when you can't get Windows Time Machine working with your NAS... Oh wait...
I suspect Macvault prefers to continue using OS X as it gives him the opportunity to complain about it, whereas were he to stick solely with Windows, he would have to find something else to complain about, as well as to someone else.
No, that's not right either. Have you ever investigated this on your system? There are plenty of hard links used by UNIX.
There are plenty of hard links, but my understanding, as that article stated, is that multiple hard links to the same file are not currently used in OS X. Or rather, if you're going to keep contradicting everyone, at least pontificate on what you believe is right instead of just saying everyone else is wrong!
Don't listen to them. I don't think they know what they're talking about.
Code:
/usr/bin/gzcat
/usr/bin/gzip
/usr/bin/gunzip
/usr/bin/zcatAre hard linked.
Code:
/bin/csh
/bin/tcshAre hard linked. So are
Code:
/usr/share/man/man3/Tcl_FSGetPathType.3tcl
/usr/share/man/man3/Tcl_FSGetTranslatedPath.3tcl
/usr/share/man/man3/Tcl_FSGetTranslatedStringPath.3tcl
/usr/share/man/man3/Tcl_FSJoinPath.3tcl
/usr/share/man/man3/Tcl_FSCopyDirectory.3tcl
/usr/share/man/man3/Tcl_FSJoinToPath.3tcl
/usr/share/man/man3/Tcl_FSData.3tcl
/usr/share/man/man3/Tcl_FSConvertToPathType.3tcl
/usr/share/man/man3/Tcl_FSLink.3tcl
/usr/share/man/man3/Tcl_FSGetInternalRep.3tcl
/usr/share/man/man3/Tcl_FSEqualPaths.3tcl
/usr/share/man/man3/Tcl_FSListVolumes.3tcl
/usr/share/man/man3/Tcl_FSRegister.3tcl
/usr/share/man/man3/Tcl_FSGetCwd.3tcl
/usr/share/man/man3/Tcl_FSNewNativePath.3tcl
/usr/share/man/man3/Tcl_AllocStatBuf.3tcl
/usr/share/man/man3/Tcl_FSOpenFileChannel.3tcl
/usr/share/man/man3/Tcl_FSRemoveDirectory.3tcl
/usr/share/man/man3/Tcl_FSStat.3tcl
/usr/share/man/man3/Tcl_FSLoadFile.3tcl
/usr/share/man/man3/Tcl_FSRenameFile.3tcl
/usr/share/man/man3/Tcl_FSGetNativePath.3tcl
/usr/share/man/man3/Tcl_FSAccess.3tcl
/usr/share/man/man3/Tcl_FSFileAttrsGet.3tcl
/usr/share/man/man3/Tcl_FSDeleteFile.3tcl
/usr/share/man/man3/Tcl_FSEvalFile.3tcl
/usr/share/man/man3/Tcl_FSUtime.3tcl
/usr/share/man/man3/Tcl_FSGetFileSystemForPath.3tcl
/usr/share/man/man3/Tcl_FSChdir.3tcl
/usr/share/man/man3/Tcl_FSUnregister.3tcl
/usr/share/man/man3/Tcl_FSSplitPath.3tcl
/usr/share/man/man3/Tcl_FSFileAttrStrings.3tcl
/usr/share/man/man3/Tcl_FSLstat.3tcl
/usr/share/man/man3/Tcl_FSPathSeparator.3tcl
/usr/share/man/man3/Tcl_FSFileSystemInfo.3tcl
/usr/share/man/man3/Tcl_FSCreateDirectory.3tcl
/usr/share/man/man3/Tcl_FSMatchInDirectory.3tcl
/usr/share/man/man3/Tcl_FSCopyFile.3tcl
/usr/share/man/man3/Tcl_FSMountsChanged.3tcl
/usr/share/man/man3/Tcl_FSGetNormalizedPath.3tcl
/usr/share/man/man3/Tcl_FSFileAttrsSet.3tclBut that is what a hard link is.
What is strange is the fact that we have a filesystem (HFS +) that was engineered with the idea that there is one file that has only one name. That's what allows you to save a file to a different location or move it, and the application picks up the change seamlessly.
Meanwhile, UNIX filesystems are created with the idea that multiple files can point to the same disk resource (hard links).
So you have a file system that was engineered to recognize that there will be one file with one name, reworked to run an operating system that expects the exact opposite: You can have many files that reference the same data. HFS was a one to one relationship it seems, while UNIX filesystems were built with one to many relations.