Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Thin Provisioned LVM



> 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
>





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org