| 1 |
On Mon, Oct 27, 2014 at 12:52 PM, Pandu Poluan <pandu@××××××.info> wrote: |
| 2 |
> |
| 3 |
> ZoL (ZFS on Linux) nowadays is implemented using DKMS instead of FUSE, thus |
| 4 |
> running in kernelspace, and (relatively) easier to put into an initramfs. |
| 5 |
|
| 6 |
Sorry about that. I should have known that, but for some reason I got |
| 7 |
that memory crossed in my brain... :) |
| 8 |
|
| 9 |
> vdevs can grow, but they can't (yet) shrink. |
| 10 |
|
| 11 |
Can you point to any docs on that, including any limitations/etc? The |
| 12 |
inability to expand raid-z the way you can do so with mdadm was one of |
| 13 |
the big things that has been keeping me away from zfs. I understand |
| 14 |
that it isn't so important when you're dealing with large numbers of |
| 15 |
disks (backblaze's storage pods come to mind), but when you have only |
| 16 |
a few disks being able to manipulate them one at a time is very |
| 17 |
useful. Growing is the more likely use case than shrinking. Then |
| 18 |
again, at some point if you want to replace smaller drives with larger |
| 19 |
ones you might want a way to remove drives from a vdev. |
| 20 |
|
| 21 |
The one thing that btrfs does that is helpful here is that it works |
| 22 |
with data in "chunks" and not at the whole drive level. That is, |
| 23 |
block 1 on drive A is not hard-mapped to block 1 on drive B in the way |
| 24 |
that it is with a traditional RAID. That makes it easy to have a |
| 25 |
non-redundant set of disks and then switch it to raid1 mode while |
| 26 |
leaving the existing data unmirrored - new chunks get mirrored, and |
| 27 |
old ones don't, and you can run a command telling the system to copy |
| 28 |
all the old data into new mirrored chunks. |
| 29 |
|
| 30 |
> And putting ZFS on SSDs... not recommended. Rather, ZFS can employ |
| 31 |
> SSDs to act as a 'write cache' for the spinning HDDs. |
| 32 |
|
| 33 |
It can operate as a read-cache as well, right? I believe you'd need |
| 34 |
separate drives/partitions for that. |
| 35 |
|
| 36 |
> |
| 37 |
> In my personal opinion, the 'killer' feature of ZFS is that it's built from |
| 38 |
> the ground up to provide maximum data integrity. |
| 39 |
|
| 40 |
That and the snapshots are actually common to both btrfs and ZFS. The |
| 41 |
main advantages of ZFS over btrfs is that the codebase is much more |
| 42 |
stable (though ZoL is a newer port of it), and that it has more |
| 43 |
enterprise-oriented features like ZIL/RAID-Z already implemented. |
| 44 |
Btrfs has license advantages as far as linux is concerned (it can |
| 45 |
actually go in the main kernel without a rewrite), and it is a bit |
| 46 |
more flexible in design and is intended as a general-purpose |
| 47 |
filesystem. |
| 48 |
|
| 49 |
Both are definitely the future of file storage compared to ext4, but |
| 50 |
they both have a lot of caveats today. |
| 51 |
|
| 52 |
What I would love to see though is something more optimized for flash |
| 53 |
like f2fs, but with the feature-completeness and integrity/snapshot |
| 54 |
capabilities of btrfs/zfs. A log-based filesystem is COW by its |
| 55 |
nature, so you just need to add that stuff in. |
| 56 |
|
| 57 |
-- |
| 58 |
Rich |
Archives