Am 02.01.11 16:52, schrieb Edward Ned Harvey:
From: Frank Lahm [mailto:frankl...@googlemail.com]
Don't all of those concerns disappear in the event of a reboot?
If you stop AFP, you could completely obliterate the BDB database, and
restart AFP, and functionally continue from where you left off. Right?
No. Apple's APIs provide semantics by which you can reference
filesystem objects by their parent directory CNID + object name. More
important in this context: these references can be stored, retrieved
and reused, eg. Finder Aliasses, Adobe InDesign and many more
applications use these semantics to store references to files.
If you nuke the CNID database, upon renumeration of the volumes all
filesystem objects are likely to assigned new and different CNIDs,
thus all references are broken.
Just like... If you shut down your Apple OSX AFP file server, move all the
files to a new upgraded file server, reassigned the old IP address and DNS name
to the new server, and enabled AFP file services on the new file server.
How do people handle the broken links issue, when they upgrade their Apple
server? If they don't bother doing anything about it, I would conclude it's no
big deal. If there is instead, some process you're supposed to follow when you
upgrade/replace your Apple AFP fileserver, I wonder if that process is
applicable to the present thread of discussion as well.
Well… on the Apple platform HFS+ (the Mac's default fs) takes care of
that, so you'd never have to worry about this issue there. On the
*nix-side of things, when running Netatalk, you'll have to store these
information in some kind of extra database, which is BDB in this case.
Initially, I only wanted check what hw to get for my ZIL and I agree
that by now, I have already decided - and ordered - two Vertex 2 EX 50GB
SSDs to handle the ZIL for my zpool, since am serving already 50 AFP
sharepoints which are accessed by 120 clients. The number of sharepoints
will eventually rise up to 250 and the number of clients will rise up to
450 and that would cause some real random workload on the zpool and the
ZIL, I guess.
The technical discussion about short stroking is nevertheless very
interesting. ;)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
