Re: [PATCH/RFC] - make ext3 more robust in the face of filesystem corruption
On Oct 18, 2006 19:26 -0500, Eric Sandeen wrote:
Well, it would also be possible to look into inode-i_blocks to see what
blocks exist past this offset, but that is complicated by the introduction
eom
introduction of ...? :)
Sorry - introduction of extents. So we can't just look into the i_blocks
{d,t,}indirect blocks to work out the maximum reasonable size for an inode
without adding decoding of extents into this code. Maybe if SEEK_DATA
is added to ext3 (patch was proposed this past week) then we could seek
past the hole efficiently. For now I'm happy to assume i_blocks * 512 is
a safe upper limit on the file size.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19-rc2-mm1 warning in invalidate_inode_pages2_range()
On Thu, 2006-10-19 at 16:02 -0700, Andrew Morton wrote: On Thu, 19 Oct 2006 15:39:06 -0700 Badari Pulavarty [EMAIL PROTECTED] wrote: Hi Zach, While running IO tests I get following messages on 2.6.19-rc2-mm1 BUG: warning at mm/truncate.c:400/invalidate_inode_pages2_range() Call Trace: [8020b481] show_trace+0x41/0x70 [8020b4c2] dump_stack+0x12/0x20 [80257f17] invalidate_inode_pages2_range+0x297/0x2e0 [8024fcb5] generic_file_direct_IO+0xf5/0x130 [8024fd64] generic_file_direct_write+0x74/0x140 [802507cc] __generic_file_aio_write_nolock+0x36c/0x4b0 [80250977] generic_file_aio_write+0x67/0xd0 [8808f6d3] :ext4dev:ext4_file_write+0x23/0xc0 DWARF2 unwinder stuck at ext4_file_write+0x23/0xc0 [ext4dev] Leftover inexact backtrace: [8027379f] do_sync_write+0xcf/0x120 [802772b7] cp_new_stat+0xe7/0x100 [8023db90] autoremove_wake_function+0x0/0x30 [804805bf] __mutex_lock_slowpath+0x1df/0x1f0 [8027408d] vfs_write+0xbd/0x180 [802747b3] sys_write+0x53/0x90 [80209c1e] system_call+0x7e/0x83 that's warning that we weren't able to invalidate some pagecache. That's not really suprising. Perhaps we should be more careful in deciding when to fail the call (ie: leaving behind a clean page is ok, leaving behind a dirty page is bad). Probably it's leaving behind dirty pagecache and you're about to lose your data. Which I bet is your own darn fault for doing silly things. What workload was in use? Running fsx and fsstress. - Badari - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] - make ext3 more robust in the face of filesystem corruption
On Oct 19, 2006 17:43 -0500, Eric Sandeen wrote: Eric Sandeen wrote: How about just tweaking the existing ext3_bread so that it lets the caller know whether or not it found an uptodate buffer? Seems conceivable that more than just the dir code might want to do a data sanity check, based on if this is a fresh read or not. Could maybe even change the *err argument to a *retval; negative on errors, else 0 == not read (found uptodate), 1 == fresh read (not found uptodate). Or is that too much overloading... I played around with this a little bit today, and it seems to have some tangible results. A fairly unsophisticated test of running find over my whole root filesystem 10 times :) with and without re-checking cached directory entries, yielded about a 10% speedup when skipping the re-checks. Is this something we want to do? Are we comfortable with only checking directory entries the first time they are read from disk? Well, we already do this on ext2 without noticable problems. As you say, if we are getting memory corruption we are in for a world of hurt in other areas. The only case that might be worth checking inside the loop is if rec_len == 0, so that we don't spin on a bad entry forever. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] - make ext3 more robust in the face of filesystem corruption
Andreas Dilger wrote: On Oct 19, 2006 17:43 -0500, Eric Sandeen wrote: Eric Sandeen wrote: How about just tweaking the existing ext3_bread so that it lets the caller know whether or not it found an uptodate buffer? Seems conceivable that more than just the dir code might want to do a data sanity check, based on if this is a fresh read or not. Could maybe even change the *err argument to a *retval; negative on errors, else 0 == not read (found uptodate), 1 == fresh read (not found uptodate). Or is that too much overloading... I played around with this a little bit today, and it seems to have some tangible results. A fairly unsophisticated test of running find over my whole root filesystem 10 times :) with and without re-checking cached directory entries, yielded about a 10% speedup when skipping the re-checks. Is this something we want to do? Are we comfortable with only checking directory entries the first time they are read from disk? Well, we already do this on ext2 without noticable problems. As you say, if we are getting memory corruption we are in for a world of hurt in other areas. The only case that might be worth checking inside the loop is if rec_len == 0, so that we don't spin on a bad entry forever. Sounds good, I'll whip up a patch; probably one patch first to add the checks fix the corruptor tests, and follow up with one to be smarter about the checks in all cases. Thanks, -eric - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
