Hi,
as you maybe remember I ported the extents and mballoc patches for 2.6.18 of
lustre-1.6.0.1 to lustre-1.4.10 and 2.6.20.
Last week we run into a problem with these patches (I never run into that
problem before, since the bug only happens on a freshly formated file
system). Well, I just looked into the cause of the problems and I'm not sure
if I maybe found a bug in the ext3-extents-2.6.18-vanilla.patch or if I'm
misunderstanding something.
for (i = 0; i < blocks_per_page; i++, iblock++) {
if (blocks[i] != 0)
continue;
rc = ext3_get_blocks_handle(handle, inode, iblock, 1, &dummy, 1, 1);
if (rc != 0 && rc != 1) {
printk(KERN_INFO "ext3_map_inode_page: error reading "
"block %ld\n", iblock);
goto out;
}
rc = 0;
/* Unmap any metadata buffers from the block mapping, to avoid
* data corruption due to direct-write from Lustre being
* clobbered by a later flush of the blockdev metadata buffer.*/
if (buffer_new(&dummy))
unmap_underlying_metadata(dummy.b_bdev,
dummy.b_blocknr);
blocks[i] = dummy.b_blocknr;
if (created)
created[i] = 1;
}
This is what we have in the extents patch from lustre-1.4.x, in lustre-1.6.0.1
it fails already with rc != 0
rc = ext3_get_blocks_handle(handle, inode, iblock, 1, &dummy, 1, 1);
if (rc) {
printk(KERN_INFO "ext3_map_inode_page: error reading "
"block %ld\n", iblock);
goto out;
}
According to the documentation of ext3_get_blocks_handle() rc>0 is a perfect
return code:
* The BKL may not be held on entry here. Be sure to take it early.
* return > 0, # of blocks mapped or allocated.
* return = 0, if plain lookup failed.
* return < 0, error case.
*/
int ext3_get_blocks_handle(handle_t *handle, struct inode *inode,
Is there something I don't see?
Thanks,
Bernd
--
Bernd Schubert
Q-Leap Networks GmbH
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
