On Sun, Jan 11, 2015 at 1:42 PM, lee <l...@yagibdah.de> wrote: > Rich Freeman <ri...@gentoo.org> writes: >> >> Generally you do backup at the filesystem layer, not at the volume >> management layer. LVM just manages a big array of disk blocks. It >> has no concept of files. > > That may require downtime while the idea of taking snapshots and then > backing up the volume is to avoid the downtime.
Sure, which is why btrfs and zfs support snapshots at the filesystem layer. You can do an lvm snapshot but it requires downtime unless you want to mount an unclean snapshot for backups. > >>>> Just create a small boot partition and give the rest to zfs. A >>>> partition is a block device, just like a disk. ZFS doesn't care if it >>>> is managing the entire disk or just a partition. >>> >>> ZFS does care: You cannot export ZFS pools residing on partitions, and >>> apparently ZFS cannot use the disk cache as efficiently when it uses >>> partitions. >> >> Cite? This seems unlikely. > > ,---- [ man zpool ] > | For pools to be portable, you must give the zpool command > | whole disks, not just partitions, so that ZFS can label the > | disks with portable EFI labels. Otherwise, disk drivers on > | platforms of different endianness will not recognize the > | disks. > `---- > > You may be able to export them, and then you don't really know what > happens when you try to import them. I didn't keep a bookmark for the > article that mentioned the disk cache. > > When you read about ZFS, you'll find that using the whole disk is > recommended while using partitions is not. Ok, I get the EFI label issue if zfs works with multiple endianness and only stores the setting in the EFI label (which seems like an odd way to do things). You didn't mention anything about disk cache and it seems unlikely that using partitions vs whole drives is going to matter here. Honestly, I feel like there is a lot of cargo cult mentality with many in the ZFS community. Another one of those "must do" things is using ECC RAM. Sure, you're more likely to end up with data corruptions without it than with it, but the same is true with ANY filesystem. I've yet to hear any reasonable argument as to why ZFS is more susceptible to memory corruption than ext4. > >>> Caching in memory is also less efficient because another >>> file system has its own cache. >> >> There is no other filesystem. ZFS is running on bare metal. It is >> just pointing to a partition on a drive (an array of blocks) instead >> of the whole drive (an array of blocks). The kernel does not cache >> partitions differently from drives. > > How do you use a /boot partition that doesn't have a file system? Oh, I thought you meant that the memory cache of zfs itself is less efficient. I'd be interested in a clear explanation as to why 10X100GB filesystems use cache differently than 1X1TB filesystem if file access is otherwise the same. However, even if having a 1GB boot partition mounted caused wasted cache space that problem is easily solved by just not mounting it except when doing kernel updates. > >>> On top of that, you have the overhead of >>> software raid for that small partition unless you can dedicate >>> hardware-raided disks for /boot. >> >> Just how often are you reading/writing from your boot partition? You >> only read from it at boot time, and you only write to it when you >> update your kernel/etc. There is no requirement for it to be raided >> in any case, though if you have multiple disks that wouldn't hurt. > > If you want to accept that the system goes down or has to be brought > down or is unable to boot because the disk you have your /boot partition > on has failed, you may be able to get away with a non-raided /boot > partition. > > When you do that, what's the advantage other than saving the software > raid? You still need to either dedicate a disk to it, or you have to > leave a part of all the other disks unused and cannot use them as a > whole for ZFS because otherwise they will be of different sizes. Sure, when I have multiple disks available and need a boot partition I RAID it with software RAID. So what? Updating your kernel /might/ be a bit slower when you do that twice a month or whatever. >> Better not buy an EFI motherboard. :) > > Yes, they are a security hazard and a PITA. Maybe I can sit it out > until they come up with something better. Security hazard? How is being able to tell your motherboard to only boot software of your own choosing a security hazard? Or are you referring to something other than UEFI? I think the pain is really only there because most of the utilities/etc haven't been updated to the new reality. In any case, I don't see it going away anytime soon. > >>>>> With ZFS at hand, btrfs seems pretty obsolete. >>>> >>>> You do realize that btrfs was created when ZFS was already at hand, >>>> right? I don't think that ZFS will be likely to make btrfs obsolete >>>> unless it adopts more dynamic desktop-oriented features (like being >>>> able to modify a vdev), and is relicensed to something GPL-compatible. >>>> Unless those happen, it is unlikely that btrfs is going to go away, >>>> unless it is replaced by something different. >>> >>> Let's say it seems /currently/ obsolete. >> >> You seem to have an interesting definition of "obsolete" - something >> which holds potential promise for the future is better described as >> "experimental." > > Can you build systems on potential promises for the future? I never claimed that you could. I just said that something which is "experimental" is not "obsolete." Something which is obsolete has no future promise. Something which is experimental is full of it. Would a potential cure for cancer be considered "obsolete" even if it isn't suitable for general use yet? > > If the resources it takes to develop btrfs would be put towards > improving ZFS, or the other way round, wouldn't that be more efficient? > We might even have a better solution available now. Of course, it's not > a good idea to remove variety, so it's a dilemma. But are the features > provided or intended to be provided and the problems both btrfs and ZFS > are trying to solve so much different that that each of them needs to > re-invent the wheel? Uh, you must be new around here. :) This argument has been raised countless times. Sure, Debian would be a bit nicer if everybody on this list quit wasting their time working on Gentoo, but it just doesn't work that way. > > What are these licensing issues good for other than preventing > solutions? You do realize that the licensing issue was created SPECIFICALLY to prevent solutions, right? It isn't like Sun didn't know what they were doing when they created the CDDL. > >> I'd actually be interested in a comparison of the underlying btrfs vs >> zfs designs. I'm not talking about implementation (bugs/etc), but the >> fundamental designs. What features are possible to add to one which >> are impossible to add to the other, what performance limitations will >> the one always suffer in comparison to the other, etc? All the >> comparisons I've seen just compare the implementations, which is >> useful if you're trying to decide what to install /right now/ but less >> so if you're trying to understand the likely future of either. > > The future is not predictable, and you can only install something > /now/. What you will be able to install in the future and what your > requirements are in the future isn't very relevant. Sure it is. You can compare the design of a bubble sort against the design of a merge sort completely independently of any implementation of either. If you're investing in a sort program that was implemented with the former with the goal of applying it to large datasets you can then realize that it makes far more sense to spend your time rewriting it to use a better algorithm than to try to optimize every instruction in the program to squeeze an extra 10% out of your O(n^2) solution. > So what's the benefit you'd get from the comparison you're interested > in? Well, for starters I'd like to understand how they both work. You'd think I run Gentoo or something. :) Understanding the maturity of the code today is certainly important. However, you don't really think that a rigorous examination of the design of something as fundamental as a filesystem isn't important for understanding the long-term direction the linux world is going to move in, right? I'm sure those working on both zfs and btrfs probably do understand the other solutions reasonably well, or at least I'd hope they would. Otherwise we're doing what you previously suggested we shouldn't do - reinventing the wheel. -- Rich
