Re: [zfs-discuss] Re: Re: Re: Proposal: multiple copies of user data
On 13/09/06, Matthew Ahrens [EMAIL PROTECTED] wrote: Dick Davies wrote: But they raise a lot of administrative issues Sure, especially if you choose to change the copies property on an existing filesystem. However, if you only set it at filesystem creation time (which is the recommended way), then it's pretty easy to address your issues: You're right, that would prevent getting into some nasty messes (I see this as closer to encryption than compression in that respect). I still feel we'd be doing the same job in several places. But I'm sure anyone who cares has a pretty good idea of my opinion, so I'll shut up now :) Thanks for taking the time to feedback on the feedback. -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Proposal: multiple copies of user data
On 9/13/06, Matthew Ahrens [EMAIL PROTECTED] wrote: Sure, if you want *everything* in your pool to be mirrored, there is no real need for this feature (you could argue that setting up the pool would be easier if you didn't have to slice up the disk though). Not necessarily. Implementing this on the FS level will still allow the administrator to turn on copies on the entire pool if since the pool is technically also a FS and the property is inherited by child FS's. Of course, this will allow the admin to turn off copies to the FS containing junk. It could be recommended in some situations. If you want to protect against disk firmware errors, bit flips, part of the disk getting scrogged, then mirroring on a single disk (whether via a mirror vdev or copies=2) solves your problem. Admittedly, these problems are probably less common that whole-disk failure, which mirroring on a single disk does not address. I beg to differ from experience that the above errors are more common than whole disk failures. It's just that we do not notice the disks are developing problems but panic when they finally fail completely. That's what happens to most of my disks anyway. Disks are much smarter nowadays with hiding bad sectors but it doesn't mean that there are none. If your precious data happens to sit on one, you'll be crying for copies. -- Just me, Wire ... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Proposal: multiple copies of user data
Celso wrote: Hopefully we can agree that you lose nothing by adding this feature, even if you personally don't see a need for it. If I read correctly user tools will show more space in use when adding copies, quotas are impacted, etc. One could argue the added confusion outweighs the addition of the feature. As others have asked I'd like to see the problem that this feature is designed to solve. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Proposal: multiple copies of user data
On 12/09/06, Celso [EMAIL PROTECTED] wrote: I think it has already been said that in many peoples experience, when a disk fails, it completely fails. Especially on laptops. Of course ditto blocks wouldn't help you in this situation either! Exactly. I still think that silent data corruption is a valid concern, one that ditto blocks would solve. Also, I am not thrilled about losing that much space for duplication of unneccessary data (caused by partitioning a disk in two). Well, you'd only be duplicating the data on the mirror. If you don't want to mirror the base OS, no one's saying you have to. For the sake of argument, let's assume: 1. disk is expensive 2. someone is keeping valuable files on a non-redundant zpool 3. they can't scrape enough vdevs to make a redundant zpool (remembering you can build vdevs out of *flat files*) Even then, to my mind: to the user, the *file* (screenplay, movie of childs birth, civ3 saved game, etc.) is the logical entity to have a 'duplication level' attached to it, and the only person who can score that is the author of the file. This proposal says the filesystem creator/admin scores the filesystem. Your argument against unneccessary data duplication applies to all 'non-special' files in the 'special' filesystem. They're wasting space too. If the user wants to make sure the file is 'safer' than others, he can just make multiple copies. Either to a USB disk/flashdrive, cdrw, dvd, ftp server, whatever. The redundancy you're talking about is what you'd get from 'cp /foo/bar.jpg /foo/bar.jpg.ok', except it's hidden from the user and causing headaches for anyone trying to comprehend, port or extend the codebase in the future. I also echo Darren's comments on zfs performing better when it has the whole disk. Me too, but a lot of laptop users dual-boot, which makes it a moot point. Hopefully we can agree that you lose nothing by adding this feature, even if you personally don't see a need for it. Sorry, I don't think we're going to agree on this one :) I've seen dozens of project proposals in the few months I've been lurking around opensolaris. Most of them have been of no use to me, but each to their own. I'm afraid I honestly think this greatly complicates the conceptual model (not to mention the technical implementation) of ZFS, and I haven't seen a convincing use case. All the best Dick. -- Rasputin :: Jack of All Trades - Master of Nuns http://number9.hellooperator.net/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Re: Re: Proposal: multiple copies of user data
Dick Davies wrote: For the sake of argument, let's assume: 1. disk is expensive 2. someone is keeping valuable files on a non-redundant zpool 3. they can't scrape enough vdevs to make a redundant zpool (remembering you can build vdevs out of *flat files*) Given those assumptions, I think that the proposed feature is the perfect solution. Simply put those files in a filesystem that has copies1. Also note that using files to back vdevs is not a recommended solution. If the user wants to make sure the file is 'safer' than others, he can just make multiple copies. Either to a USB disk/flashdrive, cdrw, dvd, ftp server, whatever. It seems to me that asking the user to solve this problem by manually making copies of all his files puts all the burden on the user/administrator and is a poor solution. For one, they have to remember to do it pretty often. For two, when they do experience some data loss, they have to manually reconstruct the files! They could have one file which has part of it missing from copy A and part of it missing from copy B. I'd hate to have to reconstruct that manually from two different files, but the proposed solution would do this transparently. The redundancy you're talking about is what you'd get from 'cp /foo/bar.jpg /foo/bar.jpg.ok', except it's hidden from the user and causing headaches for anyone trying to comprehend, port or extend the codebase in the future. Whether it's hard to understand is debatable, but this feature integrates very smoothly with the existing infrastructure and wouldn't cause any trouble when extending or porting ZFS. I'm afraid I honestly think this greatly complicates the conceptual model (not to mention the technical implementation) of ZFS, and I haven't seen a convincing use case. Just for the record, these changes are pretty trivial to implement; less than 50 lines of code changed. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
