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



> From: markw at mohawksoft.com [mailto:markw at mohawksoft.com]
> 
> nothing I have written about ZFS is fundamentally incorrect
> at this point in time

You've written like 12 pages of text in the last 2 days, which will require 20 pages and a week of reference finding, in order to respond to all the things you said wrong about zfs.  There's simply no way I have time for that.

You said "zfs blah blah is stupid."
You said "zfs blah blah incorrect."  "Bogus," "nightmare," "not desirable," etc...

It doesn't take Martin Luther King Jr. to recognize prejudice.

I respect the passion that you have for this - and I respect your expertise on lvm, and I agree 100% with the *core* of what you're saying, that for specific applications such as databases which perform their own data integrity and so forth, greater performance and better thin provisioning support can be achieved using a lighter weight file system / storage system specifically designed for those purposes.  But overshadowing a lot of that core message are incorrect generalizations and statements about zfs.  How to optimize it, and how it behaves.

I'm cherry picking 2 points to respond to, because I don't want to waste any more time of my life on this:

> says give ZFS whole disks, which is stupid

I happen to be an expert on this subject - and it's the exact opposite of stupid.  Disks have the ability to do volatile write-back caching, which is disabled by default, but greatly improves random write performance if it's enabled.  The thing is - if you give zfs the whole disk, then zfs knows no other filesystem exists on any other partition of the disk, so zfs will enable the disk write-back cache.  This is safe for zfs, but would not be safe for a bunch of other filesystems, of particular importance ufs.  I don't know if it would be safe for the various linux filesystems - but the point is - anything *other* than the whole disk, zfs cannot assume anything about the other systems using the disk and therefore will not enable the write-back.  So yes, it is smart to give zfs the whole disk.

> ZFS pool growing out of control on a sparse presented to it from a SAN

I haven't used it, but I hear that unmap is supported on illumos and closed-source solaris 11.  Without a research deep-dive, I have every reason to expect it works.



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