2010/12/24 Edward Ned Harvey <opensolarisisdeadlongliveopensola...@nedharvey.com>: >> From: Frank Lahm [mailto:frankl...@googlemail.com] >> >> With Netatalk for AFP he _is_ running a database: any AFP server needs >> to maintain a consistent mapping between _not reused_ catalog node ids >> (CNIDs) and filesystem objects. Luckily for Apple, HFS[+] and their >> Cocoa/Carbon APIs provide such a mapping making diirect use of HFS+ >> CNIDs. Unfortunately most UNIX filesystem reuse inodes and have no API >> for mapping inodes to filesystem objects. Therefor all AFP servers >> running on non-Apple OSen maintain a database providing this mapping, >> in case of Netatalk it's `cnid_dbd` using a BerkeleyDB database. > > 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. -f _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
