[Discuss] Thin Provisioned LVM

[markw at mohawksoft.com (markw at mohawksoft.com)]

> On 3/10/2015 1:03 PM, markw at mohawksoft.com 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
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>