Scott Long wrote: *trimmed*To be fair - every fs on the planet had to go through this at one time or another. We have been perhaps 'spoiled' by the odd runaway log or such that has pushed UFS to over 103% 'full', struggled on regardless, allowing us to ssh in from 12,000 miles away, kill the offender, clean up the mess, and soldier-on w/o even a reboot, let alone a crash. ZFS will (probably) get there one day as well. But at present, it has become a distraction we don't need. We're chasing promises... I'd happily trade all future interest in ZFS for better ufs, nfs, smbfs, ntfs, xfs, jfs, et al performance/safety/compatibility, ... if only 'coz that's where the bulk of the data we need to 'talk to' actually resides - not on ZFS or GPFS. Bill _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
| James Bottomley | [Ksummit-2008-discuss] Fixing the Kernel Janitors project |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| David Miller | Slow DOWN, please!!! |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
