Hello Pawel, Monday, September 10, 2007, 6:18:37 PM, you wrote:
PJD> On Mon, Sep 10, 2007 at 04:31:32PM +0100, Robert Milkowski wrote: >> Hello Pawel, >> >> Excellent job! >> >> Now I guess it would be a good idea to get writes done properly, >> even if it means make them slow (like with SVM). The end result >> would be - do you want fast wrties/slow reads go ahead with >> raid-z; if you need fast reads/slow writes go with raid-5. PJD> Writes in non-degraded mode already works. Only non-degraded mode PJD> doesn't work. My implementation is based on RAIDZ, so I'm planning to PJD> support RAID6 as well. >> btw: I'm just thinking loudly - for raid-5 writes, couldn't you >> somewhow utilize ZIL to make writes safe? I'm asking because we've >> got an ability to put zil somewhere else like NVRAM card... PJD> The problem with RAID5 is that different blocks share the same parity, PJD> which is not the case for RAIDZ. When you write a block in RAIDZ, you PJD> write the data and the parity, and then you switch the pointer in PJD> uberblock. For RAID5, you write the data and you need to update parity, PJD> which also protects some other data. Now if you write the data, but PJD> don't update the parity before a crash, you have a whole. If you update PJD> you parity before the write and a crash, you have a inconsistent with PJD> different block in the same stripe. Are you overwriting old data? I hope you're not... I don't think you should suffer from above problem in ZFS due to COW. If you are not overwriting and you're just writing to new locations from the pool perspective those changes (both new data block and checksum block) won't be active until they are both flushed and uber block is updated... right? -- Best regards, Robert Milkowski mailto:[EMAIL PROTECTED] http://milek.blogspot.com _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
