2010/12/24 Edward Ned Harvey <opensolarisisdeadlongliveopensola...@nedharvey.com>: >> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- >> boun...@opensolaris.org] On Behalf Of Stephan Budach >> >> Now, I am wondering if using a mirror of such 15k SAS drives would be a >> good-enough fit for a ZIL on a zpool that is mainly used for file services > via >> AFP and SMB. > > For supporting AFP and SMB, most likely, you would be perfectly happy simply > disabling the ZIL. You will get maximum performance... Even higher than the > world's fastest SSD or DDRDrive or any other type of storage device for > dedicated log. To determine if this is ok for you, be aware of the argument > *against* disabling the ZIL: > > In the event of an ungraceful crash, with ZIL enabled, you lose up to 30 sec > of async data, but you do not lose any sync data. > > In the event of an ungraceful crash, with ZIL disabled, you lose up to 30 > sec of async and sync data. > > In neither case do you have data corruption, or a corrupt filesystem. The > only question is about 30 seconds of sync data. You must protect this type > of data, if you're running a database, ...
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. -f _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
