> > 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.
I completely agree > For one, they have to remember to do it pretty often. > For two, when > hey 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. Again, I agree. > > 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. > OK, given this statement... > > Just for the record, these changes are pretty trivial > to implement; less > than 50 lines of code changed. and this statement, I can't see any reasons not to include it. If the changes are easy to do, don't require anymore of the zfs team's valuable time, and don't hinder other things, I would plead with you to include them, as I think they are genuinely valuable and would make zfs not only the best enterprise level filesystem, but also the best filesystem for laptops/home computers. > --matt > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discu > ss > celso This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
