James Cone wrote: > Hello All, > > Here's a possibly-silly proposal from a non-expert. > > Summarising the problem: > - there's a conflict between small ZFS record size, for good random > update performance, and large ZFS record size for good sequential read > performance >
Poor sequential read performance has not been quantified. > - COW probably makes that conflict worse > > This needs to be proven with a reproducible, real-world workload before it makes sense to try to solve it. After all, if we cannot measure where we are, how can we prove that we've improved? Note: some block devices will not exhibit the phenomenon which people seem to be worried about in this thread. There are more options than just re-architect ZFS. I'm not saying there aren't situations where there may be a problem, I'm just observing that nobody has brought data to this party. -- richard > - re-packing (~= defragmentation) would make it better, but cause > problems with the snapshot mechanism > > Proposed solution: > - keep COW > > - create a new operation that combines snapshots and cloning > > - when you're cloning, always write a tidy, re-packed layout of the data > > - if you're using the new operation, keep the existing layout as the > clone, and give the new layout to the running file-system > > Things that have to be done to make this work: > > - sort out the semantics, because the clone will be in the existing > zpool, and the file-system will move to a new zpool (not sure if I have > the terminology right) > > - sort out the transactional properties; the changes made since the > start of the operation will have to be copied across into the new layout > > Regards, > James. > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
