> On 3/10/2015 11:09 PM, [email protected] wrote: >> There are some very good reasons to NOT use ZFS, but this isn't the >> discussion I intended to start. > > Then all I will say on this subject at this time is that your problems > with ZFS seem to fall under "you're doing it wrong". ZFS best practices > are thoroughly documented and those documents do address your complaints > about ZFS.
Yes, please, oh please, put some links that describe "best practices" that address my "complaints" as there are none that anyone I have ever known have been able to find. Yes, there are some that "claim" to fix these problems, but not really or completely dismiss the architecture of the application. Remember, a lot of very high quality, very high performance, applications are designed to run on very thin disk layers, i.e. LVM, RAID, etc. ZFS introduces I/O, latency, memory requirements, CPU utilization, and other resource requirements that are otherwise not desirable in a product. A high performance application which is bottle-necked by I/O and I/O latency, will run faster against a raw disk than it will against a zvol or file in a zfs pool. > > In re Linux LVM, well, it comes as no surprise to me that the thin > provisioning mechanism feels like a bolted-on hack. LVM always felt > unfinished to me compared to other offerings like AdvFS, VxVM, even the > volume manager that IBM created to support JFS (IBM's tools and internal > consistency made up for a lot of the shortcomings in AIX). I used LVM > not because it was good but because it was the only volume manager that > Linux had. These days I try to avoid using LVM for anything other than > basic OS volumes. > > -- > Rich P. > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
