> On 3/10/2015 1:03 PM, [email protected] wrote: >> intensive for much hungrier applications. LVM is much more light weight >> and has better performance in applications that manage their own >> journalling and data integrity (like a database). >
The important part of the above paragraph that was omitted was: "the implementation of ZFS is too resource intensive for much hungrier applications" > If you're getting substantially better performance with LVM than with > ZFS then you've done something wrong. ZFS done right is only a little > worse than bare disk speeds assuming that you have enough physical RAM > for I/O cache (or dedicated ZIL and L2ARC vdevs for heavy I/O loads) and > enough CPU for raidz, compression and encryption if you are using these > features. I didn't want to talk about ZFS, I wanted to talk about LVM, but here we go with ZFS. ZFS takes significant amounts of memory. If you have high memory demands for your application, you will be competing with ZFS and significantly increase the cost of your application. ZFS does not update your disk "in-place," i.e. it is all copy-on-write. For a vast number of applications, this works pretty well, but for database class systems that manage their file blocks, this incurs extra disk I/O and impacts performance. ZFS is a nightmare for high-end commercial storage that present thin-provisioned LUNs. It is a classic strategy to present systems with a SAN LUN that grows as it is used. ZFS does not constrain itself, it grows until it takes all available space on the lun. Even if your ZFS pool shows that it is 99% empty, it will fully use the volume. There are some very good reasons to NOT use ZFS, but this isn't the discussion I intended to start. > > -- > 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
