[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: files disappear in ext3 filesystem

Thank you

both of you are right.
I had recompiled the kernel without support ram disk and ext3
so system can not mount / as ext3
now, first I reformat with several partition for different use
second, recompile the kernel to support ext3,
that is ok?
BTW: IBM is a great company.

Theodore Tso wrote:

>On Thu, Jan 17, 2002 at 10:59:42PM -0700, Andreas Dilger wrote:
>>This would indicate that the filesystem is mounted as ext2 and not ext3.
>>What does "tune2fs -l /dev/<device>" say about this device?  What does
>>/proc/partitions show?
>A very commong problem with RedHat installs seems to be that people
>don't get the initrd right (and ext3 is loaded as a module), so the
>root filesystem ends up getting mounted as ext2, even though a journal
>has been put on the device.  So "tune2fs -l /dev/XXXX" isn't the right
>test.  The right test is check out /proc/mounts and make sure it
>really is getting mounted as ext3 and not as ext2.  I'm guessing the
>problem is that it was mounted as ext2.
>>>Jan 14 09:22:33 peanut fsck: /: 143780/7241728 files (1.1% non-contiguous), 986610/14458492 blocks 
>This propensity for most RedHat users to screw up the initrd and cause
>the root to be mounted ext2 is made even worse because most newbiew
>users make the mistake of creating a single large root filesystem.
>(14 gigs, in this case).  
>Bad move....  personally, I use a 128 meg root partition, and then
>create /usr and /var partitions, and so even though my root partition
>is still ext2, I rarely have a problem with unclean shutdowns, since
>the root partition is rarely modified even though it's mounted
>read-write.  (/tmp is a symlink to /var/rtmp, and in some cases /var
>is a symlink to /usr/var, if I only want to have a / and /usr
>>While the number of error messages for the "mikelee" log is a bit high, both
>>the "i_blocks is X, should be Y" and "inode N has zero dtime" errors are not
>>unusual for an ext2 filesystem that was in use when it crashed.  What they
>>mean is (likely) that these inodes were being written to at the time the
>>systems lost power, and there is nothing ext2 can do about this.
>I agree, that's likely the cause.  Chalk this up to crappy hardware;
>what happens is that the +5 volt line from the power supply drops
>faster than the +12 volt line, and in any case, memory tends to be
>suffer the most in low voltage situations.  So in a power-fail
>situation, the memory goes insane first, but there's enough voltage
>for the DMA engine, disk controller, and disk drive to continue, such
>that garbage is written to the disk.
>In higher quality hardware, there is a power-fail interrupt which can
>be used for the hardware to abort all DMA's that are in process before
>things go to hell, but most PC-class hardware doesn't have this
>feature.  (Now that I'm at IBM, maybe I can agitate to change this;
>although IBM has 400,000 employees, and I'm in a different department
>from the ones who make hardware.  :-)
>The other workaround is to get a UPS, and then monitor the "low
>battery" indication from the UPS via the RS-232 interface, and so that
>you can do a graceful shutdown when the UPS reports that it's running
>low on batteries.  (This is basically an expensive replacement for a
>power-fail interrupt.)
>Using ext3 will usually help, since it's very likely that the blocks
>that get end up getting written as trash are on the journal, and so
>the garbaged blocks will get replayed onto the disk from the journal.
>So that will generally keep you out of trouble, even without adding
>the UPS.
>Note though ext3 helping you with crappy hardware doesn't carry over
>to other filesystems that use journals, such as reseirfs and xfs.
>Ther reason for that is that they do logical journalling, and not
>physical block journaling.  So when part of the inode table is
>modified, what is represented in the journal is a logical
>representation of the change.  For example, a series of bytes which
>indicate, "set the mod-time of the inode to XXXX".  However, this kind
>of logical logging, while space efficient since you don't write out
>the entire block, does mean that if the original block is written out
>as garbage, there isn't enough redundant data in the journal to
>reconstructed the garbaged block.
>						- Ted


Mike Lee mike li bamboonetworks com <mailto:mike li bamboonetworks com>
room 1122-1123 international bank tower
191 dong feng rd west guangzhou, p.r.c.
t) 8620-8135 1210 ext. 58
f) 8620-8135 1207

</temp/mailfoot/logo.gif> <http://www.bamboonetworks.com>

 hong kong                         guangzhou                         seoul                   tokyo

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]