> can you guess? wrote: > >> There aren't free alternatives in linux or freebsd > >> that do what zfs does, period. > >> > > > > No one said that there were: the real issue is > that there's not much reason to care, since the > available solutions don't need to be *identical* to > offer *comparable* value (i.e., they each have > different strengths and weaknesses and the net result > yields no clear winner - much as some of you would > like to believe otherwise). > Ok. So according to you, most of what ZFS does is > available elsewhere, > and the features it has that nothing else has are' > really a value add, > ar least not enough to produce a 'clear winner'. Ok, > assume for a second > that I believe that.
Unlike so many here I don't assume things lightly - and this one seems particularly shaky. can you list one other software > raid/filesystem > that as any feature (small or large) that ZFS lacks? Well, duh. > > Because if all else is really equal, and ZFS is the > only one with any > advantages then, whether those advantages are small > or not (and I don't > agree with how small you think they are - see my > other post that you've > ignored so far.) Sorry - I do need to sleep sometimes. But I'll get right to it, I assure you (or at worst soon: time has gotten away from me again and I've got an appointment to keep this afternoon). I think there is a 'clear winner' - > at least at the > moment - Things can change at any time. You don't get out much, do you? How does ZFS fall short of other open-source competitors (I'll limit myself to them, because once you get into proprietary systems - and away from the quaint limitations of Unix file systems - the list becomes utterly unmanageable)? Let us count the ways (well, at least the ones that someone as uninformed as I am about open-source features can come up with off the top of his head), starting in the volume-management arena: 1. RAID-Z, as I've explained elsewhere, is brain-damaged when it comes to effective disk utilization for small accesses (especially reads): RAID-5 offers the same space efficiency with N times the throughput for such workloads (used to be provided by mdadm on Linux unless the Linux LVM now supports it too). 2. DRDB on Linux supports remote replication (IIRC there was an earlier, simpler mechanism that also did). 3. Can you yet shuffle data off a disk such that it can be removed from a zpool? LVM on Linux supports this. 4. Last I knew, you couldn't change the number of disks in a RAID-Z stripe at all, let alone reorganize existing stripe layout on the fly. Typical hardware RAIDs can do this and I thought that Linux RAID support could as well, but can't find verification now - so I may have been remembering a proposed enhancement. And in the file system arena: 5. No user/group quotas? What *were* they thinking? The discussions about quotas here make it clear that per-filesystem quotas are not an adequate alternative: leaving aside the difficulty of simulating both user *and* group quotas using that mechanism, using it raises mount problems when very large numbers of users are involved, plus hard-link and NFS issues crossing mount points. 6. ZFS's total disregard of on-disk file contiguity can torpedo sequential-access performance by well over a decimal order of magnitude in situations where files either start out severely fragmented (due to heavily parallel write activity during their population) or become so due to fine-grained random updates. 7. ZFS's full-path COW approach increases the space overhead of snapshots compared with conventional file systems. 8. Not available on Linux. Damn - I've got to run. Perhaps others more familiar with open-source alternatives will add to this list while I'm out. - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
