[Discuss] Thin Provisioned LVM

[markw at mohawksoft.com]

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