From listopad at yahoo.com Sat Jan 1 17:24:57 2005 From: listopad at yahoo.com (Steve Listopad) Date: Sat, 1 Jan 2005 09:24:57 -0800 (PST) Subject: Advice for dealing with bad sectors on / Message-ID: <20050101172457.65716.qmail@web50906.mail.yahoo.com> All, Trying to figure out how to deal with, I assume, a dying disk that's unfortunately on / (ext3). Getting errors similar to: Dec 31 20:44:30 mybox kernel: hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error } Dec 31 20:44:30 mybox kernel: hdb: dma_intr: error=0x40 { UncorrectableError }, LBAsect=163423, high=0, low=163423, sector=163360 Dec 31 20:44:30 mybox kernel: end_request: I/O error, dev 03:41 (hdb), sector 163360 When I rebooted, the system threw me into a shell, to get me to "fix" things. So, I did an e2fsck -c -v /dev/hdb1 to attempt to fix things. The badblocks checking took 20 hours (it's a 200GB disk). Then I went through the question/answer session, hoping to get through the problems... I rebooted after this, and the machine is running, but I'm betting that failure is close. I've been trying to use smartctl to see if the bad locations were actually remapped, but the Current_Pending_Sector count is 227. I think this means that these are sectors that are queued to be remapped, but have not been. So... I have a / disk that's flaky, and believe it or not, it's under warranty, so I can replace it. Some questions: 1) Is there a way to copy data off of this disk, so that I could simply swap out the disk, turn the pc back on, and be operational? I am trying to avoid the extensive downtime associated with a plug-in-new-hd-and-reinstall scenario. Note: doing a dd from the disk to /dev/null errors out at the first bad sector. 2) I don't have a RAID setup, but I do have backups. Is there a relatively easy way to plug in a new hd, partition/format it, and copy what's on the ailing drive to it, and then somehow set it up to be the boot drive, and swap the two? any advice would be greatly appreciated. 3) Slightly off topic, but worth asking: I do backups with rsync. I have what I think is everying I need. Is there anything special (read: doing forget to rsync directories x,y,and z) so that you can reproduce the disk with the OS on it) I should be doing for backups? Thanks! Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From theman at josephdwagner.info Sat Jan 1 19:28:39 2005 From: theman at josephdwagner.info (Joseph D. Wagner) Date: Sat, 1 Jan 2005 13:28:39 -0600 Subject: Advice for dealing with bad sectors on / In-Reply-To: <20050101172457.65716.qmail@web50906.mail.yahoo.com> Message-ID: <200501011928.j01JSXGh030215@mx3.redhat.com> > Getting errors similar to: > > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: status=0x51 { DriveReady > SeekComplete Error } > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: error=0x40 { > UncorrectableError }, > LBAsect=163423, high=0, low=163423, sector=163360 > Dec 31 20:44:30 mybox kernel: end_request: I/O error, dev 03:41 (hdb), > sector > 163360 This may not be the disk; it could also be the controller. I've seen it go both ways. Any problems on hda? Try adding ide=nodma to the kernel parameters. If the problem goes away, the problem is in the kernel driver for the controller or motherboard chipset. > When I rebooted, the system threw me into a shell, to get me to "fix" > things. So, I did an e2fsck -c -v /dev/hdb1 to attempt to fix things. > The badblocks checking took 20 hours (it's a 200GB disk). Then I went > through the question/answer session, hoping to get through the problems... A better way to go about this is booting off the rescue CD and doing the e2fsck scan there. Otherwise, there could be leftover problems from running the scan off of the partition you are scanning. > Some questions: Best advice to all 3 questions: get some sort of disk imaging software. The disk imaging software may copy the bad sectors (i.e. sectors marked bad now may also be marked bad on the new drive), but you can force e2fsck to rescan bad sectors. Joseph D. Wagner From lm at bitmover.com Sat Jan 1 19:33:16 2005 From: lm at bitmover.com (Larry McVoy) Date: Sat, 1 Jan 2005 11:33:16 -0800 Subject: Advice for dealing with bad sectors on / In-Reply-To: <200501011928.j01JSXGh030215@mx3.redhat.com> References: <20050101172457.65716.qmail@web50906.mail.yahoo.com> <200501011928.j01JSXGh030215@mx3.redhat.com> Message-ID: <20050101193316.GA24291@work.bitmover.com> The one thing I'd add to Joseph's good advice is that when I see stuff like this (which I do, I manage a lot of Linux boxes) I tend to start swapping things. Put the drive in a known good system with a known good cable on the cable by itself and then see if you get errors. If you don't get errors in that situation it is likely your drive is fine and you have some bad hardware elsewhere. Hardware debugging is basically swapping parts until you find the guilty party. On Sat, Jan 01, 2005 at 01:28:39PM -0600, Joseph D. Wagner wrote: > > Getting errors similar to: > > > > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: status=0x51 { DriveReady > > SeekComplete Error } > > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: error=0x40 { > > UncorrectableError }, > > LBAsect=163423, high=0, low=163423, sector=163360 > > Dec 31 20:44:30 mybox kernel: end_request: I/O error, dev 03:41 (hdb), > > sector > > 163360 > > This may not be the disk; it could also be the controller. I've seen it go both ways. Any problems on hda? > > Try adding ide=nodma to the kernel parameters. If the problem goes away, the problem is in the kernel driver for the controller or motherboard chipset. > > > When I rebooted, the system threw me into a shell, to get me to "fix" > > things. So, I did an e2fsck -c -v /dev/hdb1 to attempt to fix things. > > The badblocks checking took 20 hours (it's a 200GB disk). Then I went > > through the question/answer session, hoping to get through the problems... > > A better way to go about this is booting off the rescue CD and doing the e2fsck scan there. Otherwise, there could be leftover problems from running the scan off of the partition you are scanning. > > > Some questions: > > Best advice to all 3 questions: get some sort of disk imaging software. > > The disk imaging software may copy the bad sectors (i.e. sectors marked bad now may also be marked bad on the new drive), but you can force e2fsck to rescan bad sectors. > > Joseph D. Wagner > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com From sct at redhat.com Sat Jan 1 22:19:23 2005 From: sct at redhat.com (Stephen C. Tweedie) Date: Sat, 01 Jan 2005 22:19:23 +0000 Subject: ext3 journal on software raid In-Reply-To: <20041231024905.GT99565@caffreys.strugglers.net> References: <20041231024905.GT99565@caffreys.strugglers.net> Message-ID: <1104617963.1948.28.camel@sisko.sctweedie.blueyonder.co.uk> Hi, On Fri, 2004-12-31 at 02:49, Andy Smith wrote: > Are the comments made in this posting from the linux-raid list > correct? > http://marc.theaimsgroup.com/?l=linux-raid&m=110444288429682&w=2 No. :-) Some of the facts are. The conclusions are not. > There is nothing that attempts expliciitly to maintain the ordering in > RAID (talking about mirroring here). Disks and IO subsystems in general don't preserve IO ordering. ext3 is designed not to care. As long as the raid device tells the truth about when the data is actually committed to disk (all of the mirror volumes are uptodate) for a given IO, ext3 should be quite happy. > What's wrong is that the journal will be mirrored (if it's a mirror). > That means that (1) its data will be written twice, which is a big deal > since ALL the i/o goes through the journal first Not true; by default, only metadata goes through the journal, not data. > and (2) the journal > is likely to be inconsistent (since it is so active) if you get one of > those creeping invisible RAID corruptions that can crop up inevitably > in RAID normal use. Umm, if soft raid is expected to have silent invisible corruptions in normal use, then you shouldn't be using it, period. That's got zero to do with journaling. --Stephen From sam at davidoffdotnet.net Sun Jan 2 04:06:40 2005 From: sam at davidoffdotnet.net (sam) Date: Sat, 1 Jan 2005 23:06:40 -0500 Subject: numerous errors on newly built md volume Message-ID: I'm constructing a raid 5 of 3 160gb sata drives. They're connected to a promise sx4 150 card, using the kernel drives (not promise's binary only drivers). the raid builds fine, as does creation of the ext3 filesystem. however, if i then run e2fsck (with the -f option since the filesystem is brand new) i get thousands of these type of errors: Inode 15461 has imagic flag set. Clear? no Inode 15462 is in use, but has dtime set. Fix? no Inode 15463 is in use, but has dtime set. Fix? no Inode 15464 is in use, but has dtime set. Fix? no Inode 15465 is in use, but has dtime set. Fix? no Inode 15466 is in use, but has dtime set. Fix? no Inode 15466 has imagic flag set. Clear? no Inode 15467 is in use, but has dtime set. Fix? no Inode 15468 is in use, but has dtime set. Fix? no Inode 15331 has compression flag set on filesystem without compression support. Clear? no Inode 15331, i_size is 15275251971216207939, should be 0. Fix? no Inode 15331, i_blocks is 154520075, should be 0. Fix? no Inode 15333, i_size is 5330692746792616550, should be 0. Fix? no Inode 15333, i_blocks is 3419793554, should be 0. Fix? no Inode 15330 has INDEX_FL flag set but is not a directory. Clear HTree index? no it appears to be picking up an error on literally every inode. i've tried rebuilding the raid several times, but always the same result. putting filesystems on the drives individually (i.e., non-raid) causes no such problems. any thoughts on what could be causing this? or what i can do to further troubleshoot? From listopad at yahoo.com Sun Jan 2 04:16:39 2005 From: listopad at yahoo.com (Steve Listopad) Date: Sat, 1 Jan 2005 20:16:39 -0800 (PST) Subject: Advice for dealing with bad sectors on / In-Reply-To: <20050101193316.GA24291@work.bitmover.com> Message-ID: <20050102041639.69419.qmail@web50910.mail.yahoo.com> All, Comments in-line. --- Larry McVoy wrote: > The one thing I'd add to Joseph's good advice is that when I see stuff like > this (which I do, I manage a lot of Linux boxes) I tend to start swapping > things. Put the drive in a known good system with a known good cable on > the cable by itself and then see if you get errors. If you don't get > errors in that situation it is likely your drive is fine and you have > some bad hardware elsewhere. > > Hardware debugging is basically swapping parts until you find the guilty > party. Thanks to both you and Joseph for making me think about things that I simply wouldn't have (or, at least not without first fixing something that wasn't broke). I would have immediately suspected the hard drive, not cables or other hardware. But, I guess that comes with experience, so thanks for sharing. The first thing I'll do is make sure that the cables are secure, and swapping cables as a quick test is easy enough to do. The controller is integrated into the MB, so that would be more problematical :) > On Sat, Jan 01, 2005 at 01:28:39PM -0600, Joseph D. Wagner wrote: > > > Getting errors similar to: > > > > > > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: status=0x51 { DriveReady > > > SeekComplete Error } > > > Dec 31 20:44:30 mybox kernel: hdb: dma_intr: error=0x40 { > > > UncorrectableError }, > > > LBAsect=163423, high=0, low=163423, sector=163360 > > > Dec 31 20:44:30 mybox kernel: end_request: I/O error, dev 03:41 (hdb), > > > sector > > > 163360 > > > > This may not be the disk; it could also be the controller. I've seen it go > both ways. Any problems on hda? No problems on hda. But, if it's the controller, that's built into the MB, so that wouldn't be good. I didn't just get DMA-type errors, there are others, like the one below. Can't say that this is a complete list, though: Dec 29 16:40:40 mybox kernel: hdb: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error } Dec 29 16:40:40 mybox kernel: hdb: read_intr: error=0x40 { UncorrectableError }, LBAsect=163423, high=0, low=163423, sector=163360 Dec 29 16:40:40 mybox kernel: end_request: I/O error, dev 03:41 (hdb), sector 163360 > > Try adding ide=nodma to the kernel parameters. If the problem goes away, > the problem is in the kernel driver for the controller or motherboard > chipset. Excellent sugguestion. Will give that a try. > > > When I rebooted, the system threw me into a shell, to get me to "fix" > > > things. So, I did an e2fsck -c -v /dev/hdb1 to attempt to fix things. > > > The badblocks checking took 20 hours (it's a 200GB disk). Then I went > > > through the question/answer session, hoping to get through the > problems... > > > > A better way to go about this is booting off the rescue CD and doing the > e2fsck scan there. Otherwise, there could be leftover problems from running > the scan off of the partition you are scanning. Ah, now that advice is somthing to put in my back pocket to remember. Never gave that a thought, since it "booted enough" to get me to a shell prompt to run e2fsck. Guess I wasn't forced to think "Rescue CD". > > > Some questions: > > > > Best advice to all 3 questions: get some sort of disk imaging software. > > > > The disk imaging software may copy the bad sectors (i.e. sectors marked bad > now may also be marked bad on the new drive), but you can force e2fsck to > rescan bad sectors. > > [SNIP] Thanks a million for all of the advice. I really appreciate it! About to go try these suggestions. Steve __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From john_freer at yahoo.com Mon Jan 3 02:46:04 2005 From: john_freer at yahoo.com (John Freer) Date: Sun, 2 Jan 2005 18:46:04 -0800 (PST) Subject: Attempting To Recover, fsck infinite looping on me Message-ID: <20050103024604.86731.qmail@web41501.mail.yahoo.com> Hey all, Had a power failure and subsequent ext3 disk corruptions. Attempting to fix, but not working. Its a 120 gig IDE disk, 3 partitions. /boot, /, and swap. Basically can't boot up since the box can't get to the system files in /usr/ or anything. So I'm booting off of a FC2 disk 1 in recovery mode and trying to fix the filesystem with e2fsck The boot partition cleaned up fine. The swap partition came back up when I did "/sbin/mkswap /dev/hda3" and "/sbin/swapon -a" I cannot, however, get fsck to run fully on /dev/hda2 (the main part of the drive). I run it and it goes through the first few recovery steps (1A, 1B, 1C), and then it comes to the problem. It lists a bunch of inodes (like 150) and asks: "Clone duplicate/bad blocks? (y)" I get about 6 of these messages with varying lists of inodes. I say yes, and fsck continues. But, after about 6 of these messages, the cycle of "Clone duplicate/bad blocks?" repeats. I looked closely at the listing of inodes, and the same 6 or so groupings of blocks are (i guess) asking to be cloned? So the program just loops, infinitely looping through the yes answers. (2 hours now). No difference if I go through manually and say no, don't clone the blocks. Just loops through the same lists. Some data: + I've got a gig of ram in the box, and (I think) swap space is on. + There may be some several 4 gig files that were corrupted. + By using top in another terminal, I find processor pegged at 99% What can I do to recover this drive? Thanks, John. ===== ----------------------------------- John J Freer 518.441.9647 / john_freer at yahoo.com From jp at enix.org Mon Jan 3 08:45:35 2005 From: jp at enix.org (=?ISO-8859-1?Q?J=E9r=F4me_Petazzoni?=) Date: Mon, 03 Jan 2005 09:45:35 +0100 Subject: Attempting To Recover, fsck infinite looping on me In-Reply-To: <20050103024604.86731.qmail@web41501.mail.yahoo.com> References: <20050103024604.86731.qmail@web41501.mail.yahoo.com> Message-ID: <41D9062F.4040307@enix.org> > I cannot, however, get fsck to run fully on /dev/hda2 (the main part > of the drive). I run it and it goes through the first few recovery > steps (1A, 1B, 1C), and then it comes to the problem. I had the same problem with debian's e2fsck 1.35 (28-Feb-2004) with a 1 terabyte volume (left it fscking for 1 week, it was still looping). I could still mount the volume however, so I mounted it read-only, and copied all the data on another disk. Some files were corrupted of course, and some of them had a wrong size (like 10 GB or even some TB), so I built an exclusion list when copying the data. After that, I had some checksums of the important files so I could find out which were corrupted and which were not. I *think* that the problem was, that the volume was full, and fsck needed free space to clone blocks or something like that. I couldn't free up space on the volume however, since when I tried it sometimes caused kernel oopses, sometimes made the volume go read-only, and when it didn't, it didn't free a single block (from du's point of view anyway). I still have an image of the damaged filesystem here (but I think I will destroy it soon, since 1 TB isn't that cheap, as you can guess). From theman at josephdwagner.info Wed Jan 5 10:51:21 2005 From: theman at josephdwagner.info (Joseph Wagner) Date: Wed, 5 Jan 2005 04:51:21 -0600 Subject: Attempting To Recover, fsck infinite looping on me In-Reply-To: <41D9062F.4040307@enix.org> References: <20050103024604.86731.qmail@web41501.mail.yahoo.com> <41D9062F.4040307@enix.org> Message-ID: <200501050451.21360.theman@josephdwagner.info> > I *think* that the problem was, that the volume was full, and fsck > needed free space to clone blocks or something like that. I couldn't > free up space on the volume however, since when I tried it sometimes > caused kernel oopses, sometimes made the volume go read-only, and when > it didn't, it didn't free a single block (from du's point of view > anyway). I'm sorry, but I cannot reproduce such an error in the mannor in which you describe; hence, I am unable to create a bug report for it. Screen output from my attempt to reproduce it is below. I will continue to try several other scenarios before giving up completely, but I thought you should know someone is looking into this problem (even though I can't yet find it). If you have more details, like screen output from during the error, feel free to contact myself or anyone else on the e2fsprogs team. Joseph D. Wagner wagnerjd at users.sourceforge.net ## Here's the status of the disk before I do anything to it. ## Notice the file system only has 3 free blocks. # e2fsck -f /dev/hdb11 e2fsck 1.35 (28-Feb-2004) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /test: 45/1048576 files (42.2% non-contiguous), 2094109/2094112 blocks ## Here I force a Duplicate Block error into the file system. ## Notice I force in 4 duplicate blocks, so the system will ## run out of space before it can clone all the duplicate blocks. # debugfs -w /dev/hdb11 debugfs 1.35 (28-Feb-2004) debugfs: modify_inode <14> Mode [0100664] User ID [0] Group ID [0] Size [49152] Creation time [1104919475] Modification time [1104911138] Access time [1104911138] Deletion time [0] Link count [1] Block count [40] 72 File flags [0x0] Generation [0xbd79555e] File acl [0] High 32bits of size [0] Fragment address [0] Fragment number [0] Fragment size [0] Direct Block #0 [1573380] Direct Block #1 [1573381] Direct Block #2 [1573382] Direct Block #3 [1573383] Direct Block #4 [1662535] Direct Block #5 [0] 1573380 Direct Block #6 [0] 1573381 Direct Block #7 [0] 1573382 Direct Block #8 [0] 1573383 Direct Block #9 [0] Direct Block #10 [0] Direct Block #11 [0] Indirect Block [0] Double Indirect Block [0] Triple Indirect Block [0] debugfs: close debugfs: quit ## Here's the first scan after I forced in the error. ## Notice it does realize that it ran out of space when ## attempting to clone the duplicate blocks. # e2fsck -f /dev/hdb11 e2fsck 1.35 (28-Feb-2004) Pass 1: Checking inodes, blocks, and sizes Duplicate blocks found... invoking duplicate block passes. Pass 1B: Rescan for duplicate/bad blocks Duplicate/bad block(s) in inode 14: 1573380 1573381 1573382 1573383 1573380 1573381 1573382 1573383 Pass 1C: Scan directories for inodes with dup blocks. Pass 1D: Reconciling duplicate blocks (There are 1 inodes containing duplicate/bad blocks.) File /test/zero512 (inode #14, mod time Wed Jan 5 01:45:38 2005) has 8 duplicate block(s), shared with 0 file(s): Clone duplicate/bad blocks? yes clone_file: Could not allocate block in ext2 filesystem returned from clone_file_block Couldn't clone file: Could not allocate block in ext2 filesystem Delete file? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #51 (3, counted=0). Fix? yes Free blocks count wrong (3, counted=0). Fix? yes /test: ***** FILE SYSTEM WAS MODIFIED ***** /test: ********** WARNING: Filesystem still has errors ********** /test: 45/1048576 files (42.2% non-contiguous), 2094112/2094112 blocks ## Here's the second pass, just to check and see what the ## first pass did and did not fix. Notice it successfully ## cloned 3 of the 4 duplicate blocks. # e2fsck -f /dev/hdb11 e2fsck 1.35 (28-Feb-2004) Pass 1: Checking inodes, blocks, and sizes Duplicate blocks found... invoking duplicate block passes. Pass 1B: Rescan for duplicate/bad blocks Duplicate/bad block(s) in inode 14: 1573383 1573383 Pass 1C: Scan directories for inodes with dup blocks. Pass 1D: Reconciling duplicate blocks (There are 1 inodes containing duplicate/bad blocks.) File /test/zero512 (inode #14, mod time Wed Jan 5 01:45:38 2005) has 2 duplicate block(s), shared with 0 file(s): Clone duplicate/bad blocks? yes clone_file: Could not allocate block in ext2 filesystem returned from clone_file_block Couldn't clone file: Could not allocate block in ext2 filesystem Delete file? no Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /test: ***** FILE SYSTEM WAS MODIFIED ***** /test: ********** WARNING: Filesystem still has errors ********** /test: 45/1048576 files (42.2% non-contiguous), 2094112/2094112 blocks From john_freer at yahoo.com Wed Jan 5 17:50:39 2005 From: john_freer at yahoo.com (John Freer) Date: Wed, 5 Jan 2005 09:50:39 -0800 (PST) Subject: Attempting To Recover, fsck infinite looping on me Message-ID: <20050105175039.90537.qmail@web41524.mail.yahoo.com> Hey All, Thanks so much for the responses. Here's some more details. Recap: 1. 120G ATA133 Drive. Unclean shutdown during power failure. 2. XP2200, Via chipset ECS K7S5A Mobo, 1G ram. 3. Drive broken into 3 partitions, / (hda2), /boot (hda1), and swap (hda3). Bulk of the drive is in / (hda2). 4. on reboot, unable to mount the / partition, boot halted. 5. on next boot, used e2fsck by booting off of RHFC2 Disk 1 in "linux rescue" mode. ie: e2fsck -vy /dev/hda2. Many errors reported, including a statement that the journal was corrupted and needed to be removed. Think it was fsck ver. 1.35. +Crunched for about 10 minutes through passes 1A, 1B, 1C, and started 1D. +fsck hangs in the middle of pass 1D, then after approx. 20 seconds hung seems to restart pass 1D. +I know it is looping/restarting because in pass 1D I get a list of 50-150 bad/duplicate blocks at different inodes. At the bottom of the list I get "Clone duplicate/bad blocks?" I then press y and get another list of blocks/inodes with the same prompt. Press y again, repeat, say, 5 times. after the last 'y', fsck hangs for like 30 seconds and then goes back to the same first list of bad blocks/inodes. The bad block/inode numbers match exactly to the first time through. +I tried answering no manually to the duplication and yes to delete duplicate. No difference. Still loops. +I downloaded the source for fsck and looked at pass1D. Not sure what/why its looping, though the souce is fairly easy to parse. +++I think there may be an error message scrolling off the top of the screen really fast after I answer 'y' to the prompt, but I can't see it on the terminal. IS THERE ANY WAY I CAN RUN e2fsck AND TRAP THE OUTPUT TO A FILE, SAY, LIKE e2fsck -vy /dev/hda >> /tmp/output.txt ? How would I format the syntax? I'll be happy to do this and make all the data available if it would help. + I also tried re-running e2fsck with -b 32764 to use another superblock for rebuilding. This resulted in the same thing. It said the journal was corrupt and that it would be removed. Then it tried to fix the drive and the same symptoms came up. 6. Since I thought this might be a memory problem thing, I also tried running only after re-enabling the swap partition. ie: mkswap /dev/hda3; swapon -a; +No difference. 7. I just ordered a new 200G drive. I'll probably install FC3 on it this weekend and then try to recover the data off the 120G drive then. But I'd sure like to get this drive back up to recover some stuff. What do you suggest next? Thanks, John. From tytso at mit.edu Wed Jan 5 19:29:34 2005 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 5 Jan 2005 14:29:34 -0500 Subject: Attempting To Recover, fsck infinite looping on me In-Reply-To: <20050105175039.90537.qmail@web41524.mail.yahoo.com> References: <20050105175039.90537.qmail@web41524.mail.yahoo.com> Message-ID: <20050105192934.GB15215@thunk.org> On Wed, Jan 05, 2005 at 09:50:39AM -0800, John Freer wrote: > > 1. 120G ATA133 Drive. Unclean shutdown during power failure. > 2. XP2200, Via chipset ECS K7S5A Mobo, 1G ram. > 3. Drive broken into 3 partitions, / (hda2), /boot (hda1), and swap > (hda3). Bulk of the drive is in / (hda2). > 4. on reboot, unable to mount the / partition, boot halted. > 5. on next boot, used e2fsck by booting off of RHFC2 Disk 1 in > "linux rescue" mode. ie: e2fsck -vy /dev/hda2. Many errors reported, > including a statement that the journal was corrupted and needed to be > removed. Think it was fsck ver. 1.35. This is e2fsck as modified by Fedora Core, which is not the same as stock e2fsprogs, but this is one I haven't heard of before. > > +Crunched for about 10 minutes through passes 1A, 1B, 1C, and > started 1D. > +fsck hangs in the middle of pass 1D, then after approx. 20 > seconds hung seems to restart pass 1D. Hmm... that doesn't make any sense. I'm not sure what's going on. > IS THERE ANY WAY I CAN RUN e2fsck AND TRAP THE OUTPUT TO A FILE, > SAY, LIKE e2fsck -vy /dev/hda >> /tmp/output.txt ? How would I > format the syntax? Use the script command. See the script(1) man page for more details. > I'll be happy to do this and make all the data available if it > would help. The other thing that you can do that would be helpful is to run the command "e2image -r /dev/hda2 | bzip2 > hda2.e2i.bz2", and make hda2.e2i.bz2 available somewhere I can download it. This will save all of the metadata blocks, although none of the data blocks. So I will be able to see the names of your files in your directories, but not the conents of any of the files. (Not that I would reveal anything that I might find, but I want to make sure you know exactly what data you would be exporting.) This will allow me to try to replicate whatever you're seeing on my computer. One final thing; have you checked your kernel logs to see if there are any hard drive errors? E2fsck fundamentally assumes that the disk drive is good; that data written to the disk, if read later on, will be reliably returned. If there are hardware problems with your disk, that can ause all sorts of wierd problems. - Ted From john_freer at yahoo.com Mon Jan 3 02:39:43 2005 From: john_freer at yahoo.com (John Freer) Date: Sun, 2 Jan 2005 18:39:43 -0800 (PST) Subject: Attempting To Recover, really need suggestions Message-ID: <20050103023943.94193.qmail@web41502.mail.yahoo.com> Hey all, Had a power failure and subsequent ext3 disk corruptions. Attempting to fix, but not working. Its a 120 gig IDE disk, 3 partitions. /boot, /, and swap. Basically can't boot up since the box can't get to the system files in /usr/ or anything. So I'm booting off of a FC2 disk 1 in recovery mode and trying to fix the filesystem with e2fsck The boot partition cleaned up fine. The swap partition came back up when I did "/sbin/mkswap /dev/hda3" and "/sbin/swapon -a" I cannot, however, get fsck to run fully on /dev/hda2 (the main part of the drive). I run it and it goes through the first few recovery steps (1A, 1B, 1C), and then it comes to the problem. It lists a bunch of inodes (like 150) and asks: "Clone duplicate/bad blocks? (y)" I get about 6 of these messages with varying lists of inodes. I say yes, and fsck continues. But, after about 6 of these messages, the cycle of "Clone duplicate/bad blocks?" repeats. I looked closely at the listing of inodes, and the same 6 or so groupings of blocks are (i guess) asking to be cloned? So the program just loops, infinitely looping through the yes answers. (2 hours now). No difference if I go through manually and say no, don't clone the blocks. Just loops through the same lists. Some data: + I've got a gig of ram in the box, and (I think) swap space is on. + There may be some several 4 gig files that were corrupted. + By using top in another terminal, I find processor pegged at 99% What can I do to recover this drive? Thanks, John. From hifumi.hisashi at lab.ntt.co.jp Tue Jan 4 11:34:09 2005 From: hifumi.hisashi at lab.ntt.co.jp (Hifumi Hisashi) Date: Tue, 04 Jan 2005 20:34:09 +0900 Subject: [PATCH] BUG on error handlings in Ext3 under I/O failure condition Message-ID: <6.0.0.20.2.20050104200330.020e0958@mailsv2.y.ecl.ntt.co.jp> Hello. I found bugs on error handlings in the functions arround the ext3 file system, which cause inadequate completions of synchronous write I/O operations when disk I/O failures occur. Both 2.4 and 2.6 have this problem. I carried out following experiment: 1. Mount a ext3 file system on a SCSI disk with ordered mode. 2. Open a file on the file system with O_SYNC|O_RDWR|O_TRUNC|O_CREAT flag. 3. Write 512 bytes data to the file by calling write() every 5 seconds, and examine return values from the syscall. from write(). 4. Disconnect the SCSI cable, and examine messages from the kernel. After the SCSI cable is disconnected, write() must fail. But the result was different: write() succeeded for a while even though messages of the kernel notified SCSI I/O error. By applying following modifications, the above problem was solved. Please consider applying this patch to the mainline kernels. Signed-off-by: Hisashi Hifumi diff -Nru linux-2.6.10-bk6/fs/buffer.c linux-2.6.10-bk6_fix/fs/buffer.c --- linux-2.6.10-bk6/fs/buffer.c 2004-12-25 06:34:58.000000000 +0900 +++ linux-2.6.10-bk6_fix/fs/buffer.c 2005-01-04 19:58:48.000000000 +0900 @@ -311,10 +311,10 @@ { struct inode * inode = dentry->d_inode; struct super_block * sb; - int ret; + int ret, err; /* sync the inode to buffers */ - write_inode_now(inode, 0); + ret = write_inode_now(inode, 0); /* sync the superblock to buffers */ sb = inode->i_sb; @@ -324,7 +324,9 @@ unlock_super(sb); /* .. finally sync the buffers to disk */ - ret = sync_blockdev(sb->s_bdev); + err = sync_blockdev(sb->s_bdev); + if (!ret) + ret = err; return ret; } diff -Nru linux-2.6.10-bk6/fs/fs-writeback.c linux-2.6.10-bk6_fix/fs/fs-writeback.c --- linux-2.6.10-bk6/fs/fs-writeback.c 2004-12-25 06:35:49.000000000 +0900 +++ linux-2.6.10-bk6_fix/fs/fs-writeback.c 2005-01-04 19:58:48.000000000 +0900 @@ -557,8 +557,9 @@ * dirty. This is primarily needed by knfsd. */ -void write_inode_now(struct inode *inode, int sync) +int write_inode_now(struct inode *inode, int sync) { + int err = 0; struct writeback_control wbc = { .nr_to_write = LONG_MAX, .sync_mode = WB_SYNC_ALL, @@ -569,10 +570,11 @@ might_sleep(); spin_lock(&inode_lock); - __writeback_single_inode(inode, &wbc); + err = __writeback_single_inode(inode, &wbc); spin_unlock(&inode_lock); if (sync) wait_on_inode(inode); + return err; } EXPORT_SYMBOL(write_inode_now); @@ -641,8 +643,11 @@ need_write_inode_now = 1; spin_unlock(&inode_lock); - if (need_write_inode_now) - write_inode_now(inode, 1); + if (need_write_inode_now) { + err2 = write_inode_now(inode, 1); + if (!err) + err = err2; + } else wait_on_inode(inode); diff -Nru linux-2.6.10-bk6/fs/inode.c linux-2.6.10-bk6_fix/fs/inode.c --- linux-2.6.10-bk6/fs/inode.c 2004-12-25 06:35:40.000000000 +0900 +++ linux-2.6.10-bk6_fix/fs/inode.c 2005-01-04 19:58:48.000000000 +0900 @@ -1035,7 +1035,7 @@ spin_unlock(&inode_lock); if (!sb || (sb->s_flags & MS_ACTIVE)) return; - write_inode_now(inode, 1); + (void) write_inode_now(inode, 1); spin_lock(&inode_lock); inodes_stat.nr_unused--; hlist_del_init(&inode->i_hash); diff -Nru linux-2.6.10-bk6/fs/jbd/commit.c linux-2.6.10-bk6_fix/fs/jbd/commit.c --- linux-2.6.10-bk6/fs/jbd/commit.c 2004-12-25 06:35:27.000000000 +0900 +++ linux-2.6.10-bk6_fix/fs/jbd/commit.c 2005-01-04 19:58:48.000000000 +0900 @@ -341,6 +341,9 @@ } spin_unlock(&journal->j_list_lock); + if (err) + __journal_abort_hard(journal); + journal_write_revoke_records(journal, commit_transaction); jbd_debug(3, "JBD: commit phase 2\n"); diff -Nru linux-2.6.10-bk6/include/linux/fs.h linux-2.6.10-bk6_fix/include/linux/fs.h --- linux-2.6.10-bk6/include/linux/fs.h 2004-12-25 06:34:27.000000000 +0900 +++ linux-2.6.10-bk6_fix/include/linux/fs.h 2005-01-04 19:58:48.000000000 +0900 @@ -1341,7 +1341,7 @@ invalidate_inode_pages(inode->i_mapping); } extern void invalidate_inode_pages2(struct address_space *mapping); -extern void write_inode_now(struct inode *, int); +extern int write_inode_now(struct inode *, int); extern int filemap_fdatawrite(struct address_space *); extern int filemap_flush(struct address_space *); extern int filemap_fdatawait(struct address_space *); diff -Nru linux-2.4.29-pre3-bk2/fs/ext3/fsync.c linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c --- linux-2.4.29-pre3-bk2/fs/ext3/fsync.c 2002-11-29 08:53:15.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c 2005-01-04 19:58:32.000000000 +0900 @@ -69,7 +69,7 @@ if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA) ret |= fsync_inode_data_buffers(inode); - ext3_force_commit(inode->i_sb); + ret |= ext3_force_commit(inode->i_sb); return ret; } diff -Nru linux-2.4.29-pre3-bk2/fs/ext3/super.c linux-2.4.29-pre3-bk2_fix/fs/ext3/super.c --- linux-2.4.29-pre3-bk2/fs/ext3/super.c 2004-11-17 20:54:21.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/ext3/super.c 2005-01-04 19:58:32.000000000 +0900 @@ -1608,12 +1608,13 @@ static int ext3_sync_fs(struct super_block *sb) { + int err; tid_t target; sb->s_dirt = 0; target = log_start_commit(EXT3_SB(sb)->s_journal, NULL); - log_wait_commit(EXT3_SB(sb)->s_journal, target); - return 0; + err = log_wait_commit(EXT3_SB(sb)->s_journal, target); + return err; } /* diff -Nru linux-2.4.29-pre3-bk2/fs/jbd/checkpoint.c linux-2.4.29-pre3-bk2_fix/fs/jbd/checkpoint.c --- linux-2.4.29-pre3-bk2/fs/jbd/checkpoint.c 2002-11-29 08:53:15.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/jbd/checkpoint.c 2005-01-04 19:58:32.000000000 +0900 @@ -142,7 +142,7 @@ spin_unlock(&journal_datalist_lock); log_start_commit(journal, transaction); unlock_journal(journal); - log_wait_commit(journal, tid); + (void) log_wait_commit(journal, tid); goto out_return_1; } diff -Nru linux-2.4.29-pre3-bk2/fs/jbd/commit.c linux-2.4.29-pre3-bk2_fix/fs/jbd/commit.c --- linux-2.4.29-pre3-bk2/fs/jbd/commit.c 2004-02-18 22:36:31.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/jbd/commit.c 2005-01-04 19:58:32.000000000 +0900 @@ -92,7 +92,7 @@ struct buffer_head *wbuf[64]; int bufs; int flags; - int err; + int err = 0; unsigned long blocknr; char *tagp = NULL; journal_header_t *header; @@ -299,6 +299,8 @@ spin_unlock(&journal_datalist_lock); unlock_journal(journal); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; /* the journal_head may have been removed now */ lock_journal(journal); goto write_out_data; @@ -326,6 +328,8 @@ spin_unlock(&journal_datalist_lock); unlock_journal(journal); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; lock_journal(journal); spin_lock(&journal_datalist_lock); continue; /* List may have changed */ @@ -351,6 +355,9 @@ } spin_unlock(&journal_datalist_lock); + if (err) + __journal_abort_hard(journal); + /* * If we found any dirty or locked buffers, then we should have * looped back up to the write_out_data label. If there weren't @@ -541,6 +548,8 @@ if (buffer_locked(bh)) { unlock_journal(journal); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; lock_journal(journal); goto wait_for_iobuf; } @@ -602,6 +611,8 @@ if (buffer_locked(bh)) { unlock_journal(journal); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; lock_journal(journal); goto wait_for_ctlbuf; } @@ -650,6 +661,8 @@ bh->b_end_io = journal_end_buffer_io_sync; submit_bh(WRITE, bh); wait_on_buffer(bh); + if (unlikely(!buffer_uptodate(bh))) + err = -EIO; put_bh(bh); /* One for getblk() */ journal_unlock_journal_head(descriptor); } @@ -661,6 +674,9 @@ skip_commit: /* The journal should be unlocked by now. */ + if (err) + __journal_abort_hard(journal); + /* Call any callbacks that had been registered for handles in this * transaction. It is up to the callback to free any allocated * memory. diff -Nru linux-2.4.29-pre3-bk2/fs/jbd/journal.c linux-2.4.29-pre3-bk2_fix/fs/jbd/journal.c --- linux-2.4.29-pre3-bk2/fs/jbd/journal.c 2004-11-17 20:54:21.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/jbd/journal.c 2005-01-04 19:58:32.000000000 +0900 @@ -582,8 +582,10 @@ * Wait for a specified commit to complete. * The caller may not hold the journal lock. */ -void log_wait_commit (journal_t *journal, tid_t tid) +int log_wait_commit (journal_t *journal, tid_t tid) { + int err = 0; + lock_kernel(); #ifdef CONFIG_JBD_DEBUG lock_journal(journal); @@ -600,6 +602,12 @@ sleep_on(&journal->j_wait_done_commit); } unlock_kernel(); + + if (unlikely(is_journal_aborted(journal))) { + printk(KERN_EMERG "journal commit I/O error\n"); + err = -EIO; + } + return err; } /* @@ -1326,7 +1334,7 @@ /* Wait for the log commit to complete... */ if (transaction) - log_wait_commit(journal, transaction->t_tid); + err = log_wait_commit(journal, transaction->t_tid); /* ...and flush everything in the log out to disk. */ lock_journal(journal); diff -Nru linux-2.4.29-pre3-bk2/fs/jbd/transaction.c linux-2.4.29-pre3-bk2_fix/fs/jbd/transaction.c --- linux-2.4.29-pre3-bk2/fs/jbd/transaction.c 2004-08-08 08:26:05.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/jbd/transaction.c 2005-01-04 19:58:32.000000000 +0900 @@ -1484,7 +1484,7 @@ * to wait for the commit to complete. */ if (handle->h_sync && !(current->flags & PF_MEMALLOC)) - log_wait_commit(journal, tid); + err = log_wait_commit(journal, tid); } kfree(handle); return err; @@ -1509,7 +1509,7 @@ goto out; } handle->h_sync = 1; - journal_stop(handle); + ret = journal_stop(handle); out: unlock_kernel(); return ret; diff -Nru linux-2.4.29-pre3-bk2/include/linux/jbd.h linux-2.4.29-pre3-bk2_fix/include/linux/jbd.h --- linux-2.4.29-pre3-bk2/include/linux/jbd.h 2004-11-17 20:54:22.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/include/linux/jbd.h 2005-01-04 19:58:32.000000000 +0900 @@ -848,7 +848,7 @@ extern int log_space_left (journal_t *); /* Called with journal locked */ extern tid_t log_start_commit (journal_t *, transaction_t *); -extern void log_wait_commit (journal_t *, tid_t); +extern int log_wait_commit (journal_t *, tid_t); extern int log_do_checkpoint (journal_t *, int); extern void log_wait_for_space(journal_t *, int nblocks); diff -Nru linux-2.4.29-pre3-bk2/mm/filemap.c linux-2.4.29-pre3-bk2_fix/mm/filemap.c --- linux-2.4.29-pre3-bk2/mm/filemap.c 2004-11-17 20:54:22.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/mm/filemap.c 2005-01-04 19:58:32.000000000 +0900 @@ -3268,7 +3268,12 @@ status = generic_osync_inode(inode, OSYNC_METADATA|OSYNC_DATA); } - err = written ? written : status; + /* + * generic_osync_inode always returns 0 or negative value. + * So 'status < written' is always true, and written should + * be returned if status >= 0. + */ + err = (status < 0) ? status : written; out: return err; Thanks, ---- Hisashi Hifumi NTT Cyber Space Laboratories From tytso at mit.edu Fri Jan 7 15:23:05 2005 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 07 Jan 2005 10:23:05 -0500 Subject: e2fsprogs 1.36-rc1 released on SourceForge Message-ID: I've just made e2fsprogs 1.36-rc1 available on Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=2406&package_id=2383&release_id=295092 Fedora Core 3 users will be strongly encouraged to upgrade to e2fsprogs 1.36, since it has numerous bug fixes to some of the Fedora-specific enhancements to e2fsprogs --- in particular, supporting on-line resizing feature using the resize inode. Although the specific bug was unlikely to be triggered, the fsck command-line parsing was botched when Red Hat added support for "fsck -C ", so that in some cases a command-line parameter to fsck could get lost. The Fedora e2fsprogs also didn't work on Big Endian machines, although no one ever reported this, so I'm guessing Fedora isn't generally built for these platforms. For people who used resize2fs on Fedora Core 3 on a filesystem created using mke2fs from FC3, and trashed their filesystem, it will be possible to recover using the following procedure after installing e2fsprogs 1.36: debugfs -w /dev/hdXXX -R "features ^resize_inode" e2fsck -f /dev/hdXXX This will remove the resize_inode feature, and correct the filesystem corruption. If you would like to use on-line resizing, you can then run ext2prepare, which should restore the resize_inode correctly. I'm asking people who are willing to be guinea pigs to download and try out e2fsprogs 1.36-rc1. Also, since I don't run Fedora myself, the e2fsprogs.spec file may need some tweaking. If you do download and try it, please let me know how it works, either way, so I know how much testing it has received. Many thanks!! - Ted From lists at mjh.name Fri Jan 7 20:44:32 2005 From: lists at mjh.name (Milan =?ISO-8859-1?Q?Holz=E4pfel?=) Date: Fri, 7 Jan 2005 21:44:32 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? Message-ID: <20050107214432.3908580b.lists@mjh.name> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No-one out there who can give me any tips for this? (Then the space to do experiments will finally be used in other ways. And I hope this mail won't be consired to impolite...) On Mon, 6 Dec 2004 15:23:15 +0100 Milan Holz?pfel wrote: > Hello, > > I got an IDE-drive which decided to get broken. Part of the extended > partition table was lost, but I was able to recover it, so I could reach > the ext3 filesystem with a size of about 135 GB. I made a copy of it > (luckily the ISP doesn't seem to need the broken drive urgently hehe) and > ran fsck on that copy. > > The first time I ran fsck I had the partition table slightly changed so > I could reach the XFS fs which comes after the ext3 partition on the > disk, which made the ext3 slightly smaller, so fsck complained and I > tried to fiddle around with modding fsck's questions somehow. This > resultet in about 2.8 GB of data (there were > 10 GB of data before. > Most importantly some tars which are sizes around 4 GB.) > > Next time I gave the block device the size which the superblock said the > FS had before, and I used fsck.ext3 with the -y option. Then I got 3 GB > of data, and not all of it was in lost+found (like it was with the first > attempt.) Much got into lost+found though, and obviously, much didn't > make it back into the fs. > > Since I still have the broken drive (and just as important, enough free > space on another drive) available for the next few days: Is there > anything more I can try? (Espacially to find one of the more recent > large tars. They have obviously been at the wrong place in the wrong > time, but that's another story.) > > TO these big files of 1+ GB: If I take an ext3 fs of 130 GB with 100+ GB > free space, can you estimate the chance of files copied with cp from > another drive getting allocated continously? Or is this possible with > ext3 at all? How big is the chance of continous allocation if these > files are read from another drive, but then sent trough bzip2, with the > output being written? Or if I use tar to create this file with the > contents read from the same filesystem? (I just though I'd ask these > too in case anyone can tell that searing for the beginning of one of > these files may well be worth the effort.) > > Here some more details on the fsck process: Amongst others, I got a lot of > these messages: > > | Deleted inode 8618118 has zero dtime. Fix? > > | Special (device/socket/fifo/symlink) file (inode 14646819) has immutable > | or append-only flag set. Clear? > > | Special (device/socket/fifo) inode 14679587 has non-zero size. Fix? > > | Inode 16187144 was part of the orphaned inode list. FIXED. > > | Inode 16187146 is in use, but has dtime set. > > | Inode 16187364 has imagic flag set. > > | Inode 16187340 has compression flag set on filesystem without compression support. > > | Inode 16187340 has INDEX_FL flag set but is not a directory. > > | Inode 16187340, i_size is 5912753600013104432, should be 0. > > | Inode 16187340, i_blocks is 2042526010, should be 0. > > | Inode 16187020 has illegal block(s). > | Illegal block #0 (2315255807) in inode 16187020. CLEARED. > | Illegal block #1 (4094814513) in inode 16187020. CLEARED. > | Illegal block #2 (3179347967) in inode 16187020. CLEARED. > | Illegal block #3 (4294967135) in inode 16187020. CLEARED. > | Illegal block #4 (3218371584) in inode 16187020. CLEARED. > | Illegal block #6 (4284530057) in inode 16187020. CLEARED. > | Illegal block #7 (2106327039) in inode 16187020. CLEARED. > | Illegal block #8 (1962902940) in inode 16187020. CLEARED. > | Illegal block #9 (1421708237) in inode 16187020. CLEARED. > | Illegal block #10 (2248146943) in inode 16187020. CLEARED. > | Illegal block #11 (2344842495) in inode 16187020. CLEARED. > | Too many illegal blocks in inode 16187020. > > And after my second fsck attempt, every further fsck does this: > > | linux root # fsck.ext3 /dev/hdc8 -y > | e2fsck 1.35 (28-Feb-2004) > | /dev/hdc8 contains a file system with errors, check forced. > | Pass 1: Checking inodes, blocks, and sizes > | Pass 2: Checking directory structure > | Pass 3: Checking directory connectivity > | '..' in /lost+found/#12713448 (12713448) is (0), should be /lost+found (7208985). > | Fix? yes > | > | Couldn't fix parent of inode 12713448: Couldn't find parent directory entry > | > | Pass 4: Checking reference counts > | Pass 5: Checking group summary information > | > | /dev/hdc8: ********** WARNING: Filesystem still has errors ********** > | > | /dev/hdc8: 86053/16990208 files (2.7% non-contiguous), 1320442/33975459 blocks > | linux root # > > Maybe these details can help you tell me whether there's any hope to > find any further data on the drive. > > TIA for any help > Milan Holz?pfel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB3vSw2wyvT2WDeWYRAjP3AJ9wfozwRdvaVznkCJSYluJ1V3rjaQCdEv2B dom+NWb23om5l0lXh8n6250= =rGlQ -----END PGP SIGNATURE----- From evilninja at gmx.net Sat Jan 8 01:45:27 2005 From: evilninja at gmx.net (Christian) Date: Sat, 08 Jan 2005 02:45:27 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? In-Reply-To: <20050107214432.3908580b.lists@mjh.name> References: <20050107214432.3908580b.lists@mjh.name> Message-ID: <41DF3B37.5050606@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Milan Holz?pfel schrieb: >>> >>>And after my second fsck attempt, every further fsck does this: >>> >>>| linux root # fsck.ext3 /dev/hdc8 -y >>>| e2fsck 1.35 (28-Feb-2004) >>>| /dev/hdc8 contains a file system with errors, check forced. >>>| Pass 1: Checking inodes, blocks, and sizes so, you did "fsck -y" and after this the fs still had unfixable errors? is there anything useful in the kernel logs, maybe hardware errors? (disk, cables, controller, memory, power) - -- BOFH excuse #299: The data on your hard drive is out of balance. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB3zs3C/PVm5+NVoYRAgLRAKDLhT79uzvhX3EP6aEGn6twAZaZ8wCgvgYR Lz6ypMFGGr6IIjQ9UdpUDgo= =YgAc -----END PGP SIGNATURE----- From lists at mjh.name Sat Jan 8 15:51:41 2005 From: lists at mjh.name (Milan =?ISO-8859-1?Q?Holz=E4pfel?=) Date: Sat, 8 Jan 2005 16:51:41 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? References: <20050107214432.3908580b.lists@mjh.name> <41DF3B37.5050606@gmx.net> Message-ID: <20050108165141.3af3b0f1.lists@mjh.name> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 08 Jan 2005 02:45:27 +0100 Christian wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Milan Holz?pfel schrieb: > >>> > >>>And after my second fsck attempt, every further fsck does this: > >>> > >>>| linux root # fsck.ext3 /dev/hdc8 -y > >>>| e2fsck 1.35 (28-Feb-2004) > >>>| /dev/hdc8 contains a file system with errors, check forced. > >>>| Pass 1: Checking inodes, blocks, and sizes > > so, you did "fsck -y" and after this the fs still had unfixable errors? > is there anything useful in the kernel logs, maybe hardware errors? (disk, > cables, controller, memory, power) IIRC yes. These fscks were run on a drive which seems to be still ok, and I think that there was nothing in the kernel logs about this drive or anything else which would be unusual, but I'm not completely sure. I guess I'll check one more time. thanks for your answer Milan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB4AGN2wyvT2WDeWYRAtn0AKCr//KChBkY+Y969lFwT+a4AQq6nACeKqKj Jjs7aPzzLsgSXyd3NcRnqwU= =MVFU -----END PGP SIGNATURE----- From evilninja at gmx.net Sat Jan 8 17:31:58 2005 From: evilninja at gmx.net (Christian) Date: Sat, 08 Jan 2005 18:31:58 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? In-Reply-To: <20050108165141.3af3b0f1.lists@mjh.name> References: <20050107214432.3908580b.lists@mjh.name> <41DF3B37.5050606@gmx.net> <20050108165141.3af3b0f1.lists@mjh.name> Message-ID: <41E0190E.4030102@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Milan Holz?pfel schrieb: > > IIRC yes. These fscks were run on a drive which seems to be still ok, > and I think that there was nothing in the kernel logs about this drive > or anything else which would be unusual, but I'm not completely sure. I > guess I'll check one more time. it's a bit strange that the ext3 gurus didn't comment on this issue yet (hint, hint:)), but as nobody else seems to suffer from said "fsck loops", you'll have to try on your own. really, just for the sake of correctnes: pull out the disk in another machine, then fsck again. in another thread Theodore Ts'o suggested to run "e2image -r" on the partition. IIRC you've made a backup from your "original corrupted data" - if this is the case, please restore from this "backup", the do $ e2image -r DEVICE file.img and make the file available for download (man e2image first, only file+dir structure should be revealed, but no content). if i understand "man e2image" correctly [1], one should be able to do "fsck.ext3 file.img" and try to reproduce your problem. just my 2?, Christian. [1] please do "man e2image", really, i've only skimmed through it.... - -- BOFH excuse #32: techtonic stress -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4BkOC/PVm5+NVoYRApFjAKDWZRrdbxYNp0SrRgqPfX/TA+jACQCg8Rr1 EbFEZcih+kklDvNinEfG4cA= =qnl1 -----END PGP SIGNATURE----- From lists at mjh.name Sat Jan 8 20:11:05 2005 From: lists at mjh.name (Milan =?ISO-8859-1?Q?Holz=E4pfel?=) Date: Sat, 8 Jan 2005 21:11:05 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? References: <20050107214432.3908580b.lists@mjh.name> <41DF3B37.5050606@gmx.net> <20050108165141.3af3b0f1.lists@mjh.name> <41E0190E.4030102@gmx.net> Message-ID: <20050108211105.2ee29e9b.lists@mjh.name> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 08 Jan 2005 18:31:58 +0100 Christian wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > it's a bit strange that the ext3 gurus didn't comment on this issue yet > (hint, hint:)), I guess they already knew about the outcome of this somehow :-D (I'll describe it below...) > but as nobody else seems to suffer from said "fsck loops", > you'll have to try on your own. really, just for the sake of correctnes: > pull out the disk in another machine, then fsck again. Hmm another IDE drive we just bought as secondary one got broken a few days before (so the big tars, which contained a backup, were not there). After I had mentioned this, the ISP's support guy agreed to switch our hardware, so this basically is another machine. The surprising thing however is the following: I did another dd from the broken drive, to a (hopefully) 100% functioning one. This time it aborted twice because of read errors (logs told read error, DMA disabled, IDE bus reset etc.) Last time I tried it didn't abort. But I simply continued one sector or two later; after the dd had reched the end of the block device, I continued again at the two abort's places. The first went just fine, the second left about 4 * 64 KB of unknown stuff, so I zeroed these 256 KB. Then I ran "fsck.ext3 -y /dev/" again, and the big surprise was that I only got a log of 3000 characters or so, and the second fsck.ext3 -y just said everything was OK. And even better, df told that there were about 14G of data on the fs. The second thing I checked were the big tars ;) and even their md5 checksums went fine. I don't know how this is possible, maybe I did some more than stupid mistake back at the beginning of December, but I for one am just happy that I got at least 90% of the data back, no matter what exactly fixed it. Maybe it's because both the broken drive and the one I copied to were on the secondary IDE bus, the broken one being the slave, so that any action on them won't interfere with the regular services using the disk on the primary bus. This might somehow have affected the first copy, but at least it went fine now... Therefore many thanks for making me check again :) (the rest of your advice is hopefully not needed now ;) ) > just my 2?, for me two very valuable ? this time *g* > Christian. thanks again, Milan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB4D5Z2wyvT2WDeWYRAqwNAKClAfoYmCQZ4gRAXYyiOvFyW1zT0QCg6lfU noCyLYfNi4teeOxjebiDeKA= =0I1z -----END PGP SIGNATURE----- From evilninja at gmx.net Sat Jan 8 23:49:52 2005 From: evilninja at gmx.net (Christian) Date: Sun, 09 Jan 2005 00:49:52 +0100 Subject: 135 GB ext3 on broken drive -- other possibilities than "e2fsck -y"? In-Reply-To: <20050108211105.2ee29e9b.lists@mjh.name> References: <20050107214432.3908580b.lists@mjh.name> <41DF3B37.5050606@gmx.net> <20050108165141.3af3b0f1.lists@mjh.name> <41E0190E.4030102@gmx.net> <20050108211105.2ee29e9b.lists@mjh.name> Message-ID: <41E071A0.1020202@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Milan Holz?pfel schrieb: > > (the rest of your advice is hopefully not needed now ;) ) glad to hear that ;) i wished i've had your luck some time ago - a raid controller went mad and 100GB ext3 were screwed and no fsck was able to do the magic.... Christian - -- BOFH excuse #249: Unfortunately we have run out of bits/bytes/whatever. Don't worry, the next supply will be coming next week. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4HGfC/PVm5+NVoYRAsV0AJ9RtSHpTkY9eqZ8OWIb1qsirfqgLgCfXg04 +AOsOQgSW5D+2B2NKXmh2T4= =Se7Z -----END PGP SIGNATURE----- From bunk at stusta.de Thu Jan 6 22:50:51 2005 From: bunk at stusta.de (Adrian Bunk) Date: Thu, 6 Jan 2005 23:50:51 +0100 Subject: [2.6 patch] fs/ext3/: possible cleanups Message-ID: <20050106225051.GF28628@stusta.de> The patch below contains the following cleanups: - make some needlessly global code static - super.c: remove the unused global function ext3_panic Please comment ib whether this patch is correct or conflicts with pending changes. diffstat output: fs/ext3/balloc.c | 2 fs/ext3/dir.c | 2 fs/ext3/inode.c | 4 fs/ext3/resize.c | 4 fs/ext3/super.c | 45 ++----- fs/ext3/xattr.c | 242 +++++++++++++++++++-------------------- fs/ext3/xattr.h | 8 - include/linux/ext3_fs.h | 10 - include/linux/ext3_jbd.h | 2 9 files changed, 143 insertions(+), 176 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.10-mm2-full/fs/ext3/balloc.c.old 2005-01-06 23:19:18.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/balloc.c 2005-01-06 23:19:26.000000000 +0100 @@ -1451,7 +1451,7 @@ } } -int ext3_group_sparse(int group) +static int ext3_group_sparse(int group) { return (test_root(group, 3) || test_root(group, 5) || test_root(group, 7)); --- linux-2.6.10-mm2-full/fs/ext3/dir.c.old 2005-01-06 23:20:02.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/dir.c 2005-01-06 23:20:11.000000000 +0100 @@ -306,7 +306,7 @@ } -struct dir_private_info *create_dir_info(loff_t pos) +static struct dir_private_info *create_dir_info(loff_t pos) { struct dir_private_info *p; --- linux-2.6.10-mm2-full/include/linux/ext3_jbd.h.old 2005-01-06 23:20:34.000000000 +0100 +++ linux-2.6.10-mm2-full/include/linux/ext3_jbd.h 2005-01-06 23:21:06.000000000 +0100 @@ -46,8 +46,6 @@ EXT3_XATTR_TRANS_BLOCKS - 2 + \ 2*EXT3_QUOTA_TRANS_BLOCKS) -extern int ext3_writepage_trans_blocks(struct inode *inode); - /* Delete operations potentially hit one directory's namespace plus an * entire inode, plus arbitrary amounts of bitmap/indirection data. Be * generous. We can grow the delete transaction later if necessary. */ --- linux-2.6.10-mm2-full/fs/ext3/inode.c.old 2005-01-06 23:21:49.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/inode.c 2005-01-06 23:22:20.000000000 +0100 @@ -39,6 +39,8 @@ #include "xattr.h" #include "acl.h" +static int ext3_writepage_trans_blocks(struct inode *inode); + /* * Test whether an inode is a fast symlink. */ @@ -2807,7 +2809,7 @@ * block and work out the exact number of indirects which are touched. Pah. */ -int ext3_writepage_trans_blocks(struct inode *inode) +static int ext3_writepage_trans_blocks(struct inode *inode) { int bpp = ext3_journal_blocks_per_page(inode); int indirects = (EXT3_NDIR_BLOCKS % bpp) ? 5 : 3; --- linux-2.6.10-mm2-full/fs/ext3/resize.c.old 2005-01-06 23:22:37.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/resize.c 2005-01-06 23:22:50.000000000 +0100 @@ -285,8 +285,8 @@ * sequence of powers of 3, 5, and 7: 1, 3, 5, 7, 9, 25, 27, 49, 81, ... * For a non-sparse filesystem it will be every group: 1, 2, 3, 4, ... */ -unsigned ext3_list_backups(struct super_block *sb, unsigned *three, - unsigned *five, unsigned *seven) +static unsigned ext3_list_backups(struct super_block *sb, unsigned *three, + unsigned *five, unsigned *seven) { unsigned *min = three; int mult = 3; --- linux-2.6.10-mm2-full/include/linux/ext3_fs.h.old 2005-01-06 23:23:16.000000000 +0100 +++ linux-2.6.10-mm2-full/include/linux/ext3_fs.h 2005-01-06 23:27:28.000000000 +0100 @@ -793,25 +793,15 @@ extern void __ext3_std_error (struct super_block *, const char *, int); extern void ext3_abort (struct super_block *, const char *, const char *, ...) __attribute__ ((format (printf, 3, 4))); -extern NORET_TYPE void ext3_panic (struct super_block *, const char *, - const char *, ...) - __attribute__ ((NORET_AND format (printf, 3, 4))); extern void ext3_warning (struct super_block *, const char *, const char *, ...) __attribute__ ((format (printf, 3, 4))); extern void ext3_update_dynamic_rev (struct super_block *sb); -extern void ext3_put_super (struct super_block *); -extern void ext3_write_super (struct super_block *); -extern void ext3_write_super_lockfs (struct super_block *); -extern void ext3_unlockfs (struct super_block *); -extern int ext3_remount (struct super_block *, int *, char *); -extern int ext3_statfs (struct super_block *, struct kstatfs *); #define ext3_std_error(sb, errno) \ do { \ if ((errno)) \ __ext3_std_error((sb), __FUNCTION__, (errno)); \ } while (0) -extern const char *ext3_decode_error(struct super_block *sb, int errno, char nbuf[16]); /* * Inodes and files operations --- linux-2.6.10-mm2-full/fs/ext3/super.c.old 2005-01-06 23:23:39.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/super.c 2005-01-06 23:28:34.000000000 +0100 @@ -50,6 +50,13 @@ static void ext3_clear_journal_err(struct super_block * sb, struct ext3_super_block * es); static int ext3_sync_fs(struct super_block *sb, int wait); +static const char *ext3_decode_error(struct super_block * sb, int errno, + char nbuf[16]); +static int ext3_remount (struct super_block * sb, int * flags, char * data); +static int ext3_statfs (struct super_block * sb, struct kstatfs * buf); +static void ext3_unlockfs(struct super_block *sb); +static void ext3_write_super (struct super_block * sb); +static void ext3_write_super_lockfs(struct super_block *sb); /* * Wrappers for journal_start/end. @@ -178,7 +185,8 @@ ext3_handle_error(sb); } -const char *ext3_decode_error(struct super_block * sb, int errno, char nbuf[16]) +static const char *ext3_decode_error(struct super_block * sb, int errno, + char nbuf[16]) { char *errstr = NULL; @@ -261,29 +269,6 @@ journal_abort(EXT3_SB(sb)->s_journal, -EIO); } -/* Deal with the reporting of failure conditions while running, such as - * inconsistencies in operation or invalid system states. - * - * Use ext3_error() for cases of invalid filesystem states, as that will - * record an error on disk and force a filesystem check on the next boot. - */ -NORET_TYPE void ext3_panic (struct super_block * sb, const char * function, - const char * fmt, ...) -{ - va_list args; - - va_start(args, fmt); - printk(KERN_CRIT "EXT3-fs error (device %s): %s: ",sb->s_id, function); - vprintk(fmt, args); - printk("\n"); - va_end(args); - - /* this is to prevent panic from syncing this filesystem */ - /* AKPM: is this sufficient? */ - sb->s_flags |= MS_RDONLY; - panic ("EXT3-fs panic forced\n"); -} - void ext3_warning (struct super_block * sb, const char * function, const char * fmt, ...) { @@ -386,7 +371,7 @@ } } -void ext3_put_super (struct super_block * sb) +static void ext3_put_super (struct super_block * sb) { struct ext3_sb_info *sbi = EXT3_SB(sb); struct ext3_super_block *es = sbi->s_es; @@ -2018,7 +2003,7 @@ * This implicitly triggers the writebehind on sync(). */ -void ext3_write_super (struct super_block * sb) +static void ext3_write_super (struct super_block * sb) { if (down_trylock(&sb->s_lock) == 0) BUG(); @@ -2041,7 +2026,7 @@ * LVM calls this function before a (read-only) snapshot is created. This * gives us a chance to flush the journal completely and mark the fs clean. */ -void ext3_write_super_lockfs(struct super_block *sb) +static void ext3_write_super_lockfs(struct super_block *sb) { sb->s_dirt = 0; @@ -2062,7 +2047,7 @@ * Called by LVM after the snapshot is done. We need to reset the RECOVER * flag here, even though the filesystem is not technically dirty yet. */ -void ext3_unlockfs(struct super_block *sb) +static void ext3_unlockfs(struct super_block *sb) { if (!(sb->s_flags & MS_RDONLY)) { lock_super(sb); @@ -2074,7 +2059,7 @@ } } -int ext3_remount (struct super_block * sb, int * flags, char * data) +static int ext3_remount (struct super_block * sb, int * flags, char * data) { struct ext3_super_block * es; struct ext3_sb_info *sbi = EXT3_SB(sb); @@ -2146,7 +2131,7 @@ return 0; } -int ext3_statfs (struct super_block * sb, struct kstatfs * buf) +static int ext3_statfs (struct super_block * sb, struct kstatfs * buf) { struct ext3_super_block *es = EXT3_SB(sb)->s_es; unsigned long overhead; --- linux-2.6.10-mm2-full/fs/ext3/xattr.h.old 2005-01-06 23:29:45.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/xattr.h 2005-01-06 23:32:17.000000000 +0100 @@ -65,10 +65,8 @@ extern ssize_t ext3_listxattr(struct dentry *, char *, size_t); extern int ext3_xattr_get(struct inode *, int, const char *, void *, size_t); -extern int ext3_xattr_list(struct inode *, char *, size_t); extern int ext3_xattr_set(struct inode *, int, const char *, const void *, size_t, int); extern int ext3_xattr_set_handle(handle_t *, struct inode *, int, const char *,const void *,size_t,int); -extern int ext3_xattr_block_set(handle_t *, struct inode *, int, const char *,const void *,size_t,int); extern void ext3_xattr_delete_inode(handle_t *, struct inode *); extern void ext3_xattr_put_super(struct super_block *); @@ -88,12 +86,6 @@ } static inline int -ext3_xattr_list(struct inode *inode, void *buffer, size_t size) -{ - return -EOPNOTSUPP; -} - -static inline int ext3_xattr_set(struct inode *inode, int name_index, const char *name, const void *value, size_t size, int flags) { --- linux-2.6.10-mm2-full/fs/ext3/xattr.c.old 2005-01-06 23:28:52.000000000 +0100 +++ linux-2.6.10-mm2-full/fs/ext3/xattr.c 2005-01-06 23:33:06.000000000 +0100 @@ -139,22 +139,11 @@ } /* - * Inode operation listxattr() - * - * dentry->d_inode->i_sem: don't care - */ -ssize_t -ext3_listxattr(struct dentry *dentry, char *buffer, size_t size) -{ - return ext3_xattr_list(dentry->d_inode, buffer, size); -} - -/* * ext3_xattr_block_get() * * routine looks for attribute in EA block and returns it's value and size */ -int +static int ext3_xattr_block_get(struct inode *inode, int name_index, const char *name, void *buffer, size_t buffer_size) { @@ -250,7 +239,7 @@ * * routine looks for attribute in inode body and returns it's value and size */ -int +static int ext3_xattr_ibody_get(struct inode *inode, int name_index, const char *name, void *buffer, size_t buffer_size) { @@ -352,7 +341,7 @@ * * generate list of attributes stored in EA block */ -int +static int ext3_xattr_block_list(struct inode *inode, char *buffer, size_t buffer_size) { struct buffer_head *bh = NULL; @@ -428,7 +417,7 @@ * * generate list of attributes stored in inode body */ -int +static int ext3_xattr_ibody_list(struct inode *inode, char *buffer, size_t buffer_size) { struct ext3_xattr_entry *last; @@ -507,7 +496,7 @@ * Returns a negative error number on failure, or the number of bytes * used / required on success. */ -int +static int ext3_xattr_list(struct inode *inode, char *buffer, size_t buffer_size) { int size = buffer_size; @@ -546,6 +535,17 @@ } /* + * Inode operation listxattr() + * + * dentry->d_inode->i_sem: don't care + */ +ssize_t +ext3_listxattr(struct dentry *dentry, char *buffer, size_t size) +{ + return ext3_xattr_list(dentry->d_inode, buffer, size); +} + +/* * If the EXT3_FEATURE_COMPAT_EXT_ATTR feature of this file system is * not set, set it. */ @@ -571,7 +571,7 @@ * search attribute and calculate free space in inode body * NOTE: free space includes space our attribute hold */ -int +static int ext3_xattr_ibody_find(struct inode *inode, int name_index, const char *name, int *free) { @@ -638,7 +638,7 @@ * search attribute and calculate free space in EA block (if it allocated) * NOTE: free space includes space our attribute hold */ -int +static int ext3_xattr_block_find(struct inode *inode, int name_index, const char *name, int *free) { @@ -698,7 +698,7 @@ * * this routine add/remove/replace attribute in inode body */ -int +static int ext3_xattr_ibody_set(handle_t *handle, struct inode *inode, int name_index, const char *name, const void *value, size_t value_len, int flags) @@ -846,112 +846,11 @@ } /* - * ext3_xattr_set_handle() - * - * Create, replace or remove an extended attribute for this inode. Buffer - * is NULL to remove an existing extended attribute, and non-NULL to - * either replace an existing extended attribute, or create a new extended - * attribute. The flags XATTR_REPLACE and XATTR_CREATE - * specify that an extended attribute must exist and must not exist - * previous to the call, respectively. - * - * Returns 0, or a negative error number on failure. - */ -int -ext3_xattr_set_handle(handle_t *handle, struct inode *inode, int name_index, - const char *name, const void *value, size_t value_len, - int flags) -{ - int free1 = -1, free2 = -1; - int err, where = 0, total; - int name_len; - - ea_idebug(inode, "name=%d.%s, value=%p, value_len=%ld", - name_index, name, value, (long)value_len); - - if (IS_RDONLY(inode)) - return -EROFS; - if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) - return -EPERM; - if (value == NULL) - value_len = 0; - if (name == NULL) - return -EINVAL; - name_len = strlen(name); - if (name_len > 255 || value_len > inode->i_sb->s_blocksize) - return -ERANGE; - down_write(&EXT3_I(inode)->xattr_sem); - -#define EX_FOUND_IN_IBODY 1 -#define EX_FOUND_IN_BLOCK 2 - - /* try to find attribute in inode body */ - err = ext3_xattr_ibody_find(inode, name_index, name, &free1); - if (err == 0) { - /* found EA in inode */ - where = EX_FOUND_IN_IBODY; - } else if (err == -ENOENT) { - /* there is no such attribute in inode body */ - /* try to find attribute in dedicated block */ - err = ext3_xattr_block_find(inode, name_index, name, &free2); - if (err != 0 && err != -ENOENT) { - /* not found EA in block */ - goto finish; - } else if (err == 0) { - /* found EA in block */ - where = EX_FOUND_IN_BLOCK; - } - } else - goto finish; - - /* check flags: may replace? may create ? */ - if (where && (flags & XATTR_CREATE)) { - err = -EEXIST; - goto finish; - } else if (!where && (flags & XATTR_REPLACE)) { - err = -ENODATA; - goto finish; - } - - /* check if we have enough space to store attribute */ - total = EXT3_XATTR_LEN(strlen(name)) + value_len; - if (total > free1 && free2 > 0 && total > free2) { - /* have no enough space */ - err = -ENOSPC; - goto finish; - } - - /* there are two cases when we want to remove EA from original storage: - * a) EA is stored in the inode, but new value doesn't fit - * b) EA is stored in the block, but new value fit in inode - */ - if (where == EX_FOUND_IN_IBODY && total > free1) - ext3_xattr_ibody_set(handle, inode, name_index, name, - NULL, 0, flags); - else if (where == EX_FOUND_IN_BLOCK && total <= free1) - ext3_xattr_block_set(handle, inode, name_index, - name, NULL, 0, flags); - - /* try to store EA in inode body */ - err = ext3_xattr_ibody_set(handle, inode, name_index, name, - value, value_len, flags); - if (err) { - /* can't store EA in inode body: try to store in block */ - err = ext3_xattr_block_set(handle, inode, name_index, name, - value, value_len, flags); - } - -finish: - up_write(&EXT3_I(inode)->xattr_sem); - return err; -} - -/* * ext3_xattr_block_set() * * this routine add/remove/replace attribute in EA block */ -int +static int ext3_xattr_block_set(handle_t *handle, struct inode *inode, int name_index, const char *name, const void *value, size_t value_len, int flags) @@ -1206,6 +1105,107 @@ } /* + * ext3_xattr_set_handle() + * + * Create, replace or remove an extended attribute for this inode. Buffer + * is NULL to remove an existing extended attribute, and non-NULL to + * either replace an existing extended attribute, or create a new extended + * attribute. The flags XATTR_REPLACE and XATTR_CREATE + * specify that an extended attribute must exist and must not exist + * previous to the call, respectively. + * + * Returns 0, or a negative error number on failure. + */ +int +ext3_xattr_set_handle(handle_t *handle, struct inode *inode, int name_index, + const char *name, const void *value, size_t value_len, + int flags) +{ + int free1 = -1, free2 = -1; + int err, where = 0, total; + int name_len; + + ea_idebug(inode, "name=%d.%s, value=%p, value_len=%ld", + name_index, name, value, (long)value_len); + + if (IS_RDONLY(inode)) + return -EROFS; + if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + return -EPERM; + if (value == NULL) + value_len = 0; + if (name == NULL) + return -EINVAL; + name_len = strlen(name); + if (name_len > 255 || value_len > inode->i_sb->s_blocksize) + return -ERANGE; + down_write(&EXT3_I(inode)->xattr_sem); + +#define EX_FOUND_IN_IBODY 1 +#define EX_FOUND_IN_BLOCK 2 + + /* try to find attribute in inode body */ + err = ext3_xattr_ibody_find(inode, name_index, name, &free1); + if (err == 0) { + /* found EA in inode */ + where = EX_FOUND_IN_IBODY; + } else if (err == -ENOENT) { + /* there is no such attribute in inode body */ + /* try to find attribute in dedicated block */ + err = ext3_xattr_block_find(inode, name_index, name, &free2); + if (err != 0 && err != -ENOENT) { + /* not found EA in block */ + goto finish; + } else if (err == 0) { + /* found EA in block */ + where = EX_FOUND_IN_BLOCK; + } + } else + goto finish; + + /* check flags: may replace? may create ? */ + if (where && (flags & XATTR_CREATE)) { + err = -EEXIST; + goto finish; + } else if (!where && (flags & XATTR_REPLACE)) { + err = -ENODATA; + goto finish; + } + + /* check if we have enough space to store attribute */ + total = EXT3_XATTR_LEN(strlen(name)) + value_len; + if (total > free1 && free2 > 0 && total > free2) { + /* have no enough space */ + err = -ENOSPC; + goto finish; + } + + /* there are two cases when we want to remove EA from original storage: + * a) EA is stored in the inode, but new value doesn't fit + * b) EA is stored in the block, but new value fit in inode + */ + if (where == EX_FOUND_IN_IBODY && total > free1) + ext3_xattr_ibody_set(handle, inode, name_index, name, + NULL, 0, flags); + else if (where == EX_FOUND_IN_BLOCK && total <= free1) + ext3_xattr_block_set(handle, inode, name_index, + name, NULL, 0, flags); + + /* try to store EA in inode body */ + err = ext3_xattr_ibody_set(handle, inode, name_index, name, + value, value_len, flags); + if (err) { + /* can't store EA in inode body: try to store in block */ + err = ext3_xattr_block_set(handle, inode, name_index, name, + value, value_len, flags); + } + +finish: + up_write(&EXT3_I(inode)->xattr_sem); + return err; +} + +/* * Second half of ext3_xattr_set_handle(): Update the file system. */ static int From adobriyan at mail.ru Sun Jan 9 09:44:16 2005 From: adobriyan at mail.ru (Alexey Dobriyan) Date: Sun, 9 Jan 2005 11:44:16 +0200 Subject: [PATCH] ext3: s/0/NULL/ in pointer context Message-ID: <200501091144.16341.adobriyan@mail.ru> Signed-off-by: Alexey Dobriyan Index: linux-2.6.10-bk11-warnings/fs/ext3/inode.c =================================================================== --- linux-2.6.10-bk11-warnings/fs/ext3/inode.c (revision 11) +++ linux-2.6.10-bk11-warnings/fs/ext3/inode.c (revision 12) @@ -803,7 +803,7 @@ if (create) { handle = ext3_journal_current_handle(); - J_ASSERT(handle != 0); + J_ASSERT(handle != NULL); } ret = ext3_get_block_handle(handle, inode, iblock, bh_result, create, 1); @@ -876,7 +876,7 @@ bh = sb_getblk(inode->i_sb, dummy.b_blocknr); if (buffer_new(&dummy)) { J_ASSERT(create != 0); - J_ASSERT(handle != 0); + J_ASSERT(handle != NULL); /* Now that we do not always journal data, we should keep in mind whether this should Index: linux-2.6.10-bk11-warnings/fs/ext3/fsync.c =================================================================== --- linux-2.6.10-bk11-warnings/fs/ext3/fsync.c (revision 11) +++ linux-2.6.10-bk11-warnings/fs/ext3/fsync.c (revision 12) @@ -47,7 +47,7 @@ struct inode *inode = dentry->d_inode; int ret = 0; - J_ASSERT(ext3_journal_current_handle() == 0); + J_ASSERT(ext3_journal_current_handle() == NULL); /* * data=writeback: From capsthorne at yahoo.co.uk Wed Jan 19 09:16:37 2005 From: capsthorne at yahoo.co.uk (Geoff) Date: Wed, 19 Jan 2005 09:16:37 +0000 Subject: Policy after fsck fixes errors Message-ID: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> Hello, Yesterday evening this box crashed and, for once, ext3 was not able to recover automatically. There was an "unexpected inconsistency inode xxxxx has imagic flag set" error and the system would not boot. I fscked from my rescue disk and I guess 20 or 30 errors were fixed by me just selecting "y" at the prompt. The system then booted and, so far as I can tell, the only problem was that my firefox profile was corrupt (I have a feeling that an old configuration got restored instead of the current one). That was easily fixed, but I am left wondering whether there might not be other, less immediately detectable, problems remaining which could show up later. Since fixing the profile I have forced another fsck which (as you would expect I suppose), does not throw up any errors. I have a backup hdd (slightly out of date, my fault), which I could turn to, but I am wondering: (a) Would you regard even a successful fsck in circumstances such as these as an emergency measure, and revert to your backup as a matter of course ? (b) Are there any other diagnostics I could run to confirm the integrity of my data? TIA Geoff From tytso at mit.edu Wed Jan 19 13:56:53 2005 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 19 Jan 2005 08:56:53 -0500 Subject: Policy after fsck fixes errors In-Reply-To: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> References: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> Message-ID: <20050119135653.GF15042@thunk.org> On Wed, Jan 19, 2005 at 09:16:37AM +0000, Geoff wrote: > > Yesterday evening this box crashed and, for once, ext3 was > not able to recover automatically. There was an > "unexpected inconsistency inode xxxxx has imagic flag set" > error and the system would not boot. I fscked from my > rescue disk and I guess 20 or 30 errors were fixed by me > just selecting "y" at the prompt. Did you save all of the other fsck messages? Was there any messages about directory entries to deleted files being deleted, or files ending up in lost+found? This sounds like garbage was written into your inode table; depending on where the garbage was written, yes there could have been files that ended up going missing as a result. > The system then booted and, so far as I can tell, the only > problem was that my firefox profile was corrupt (I have a > feeling that an old configuration got restored instead of > the current one). That was easily fixed, but I am left > wondering whether there might not be other, less > immediately detectable, problems remaining which could show > up later. Since fixing the profile I have forced another > fsck which (as you would expect I suppose), does not throw > up any errors. Right, there would be no further filesystem corruption (unless whatever caused garbage to appear in the first place --- bad controller, bad IDE/SCSI cable, failing hard drive, etc. --- is still causing additional damage to the filesystem). However, files might be missing. It might be worthwhile to compare the files on your backup hdd with your current filesystem, to see if you have any missing files. It's also possible I suppose that data blocks were actually corrupted, but that really depends on how the inode table blocks got corrupted in the frist place. > (b) Are there any other diagnostics I could run to confirm > the integrity of my data? Aside from comparisons to backups, if you had been using programs like cfv to calculate checksums of all of your files, you could use them to check the data integrity of your data files. On rpm-based systems, you can also do things like rpm -Va to check the checksums of the installed files. This won't check your data files, and will raise false positives caused by config files that you have since modified, but it might give you a hint that there is greater damage, or put your mind at ease that things are more likely to be OK. Good luck, - Ted From capsthorne at yahoo.co.uk Wed Jan 19 14:37:52 2005 From: capsthorne at yahoo.co.uk (Geoff) Date: Wed, 19 Jan 2005 14:37:52 +0000 Subject: Policy after fsck fixes errors In-Reply-To: <20050119135653.GF15042@thunk.org> References: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> <20050119135653.GF15042@thunk.org> Message-ID: <20050119143752.42531623.capsthorne@yahoo.co.uk> On Wed, 19 Jan 2005 08:56:53 -0500 "Theodore Ts'o" wrote: > On Wed, Jan 19, 2005 at 09:16:37AM +0000, Geoff wrote: > > > > Yesterday evening this box crashed and, for once, ext3 > > was not able to recover automatically. There was an > > "unexpected inconsistency inode xxxxx has imagic flag > > set" error and the system would not boot. I fscked from > > my rescue disk and I guess 20 or 30 errors were fixed by > > me just selecting "y" at the prompt. > > Did you save all of the other fsck messages? Was there > any messages about directory entries to deleted files > being deleted, or files ending up in lost+found? Thanks for responding Ted. Why do problems like this always occur late at night? I use the box for my business and went into idiot-mode just to try and get it working again before bed and today's work. I did not therefore, do any logging or even pay proper attention to fsck's output. I do remember that fsck took at least two passes and ISTR that, duplicates were found and stuff was deleted. After I had posted to the list this morning I got my thinking apparatus into better order and remembered to check lost+found. There are two directories there, both of which appear to be empty. I noted the username which had written them and did a system-wide find for files created by that user - there was just one other file (cert8.db), in the copy of the broken firefox profile directory I saved before creating the new one - so I guess that at some point fsck must have asked me if I wanted it to do that. This encourages me to believe that the situation may not be as bad as I feared. I have decided to wait and see at least until weekend when I shall have a little more time. > ... there would be no further filesystem corruption > (unless whatever caused garbage to appear in the first > place --- bad controller, bad IDE/SCSI cable, failing hard > drive, etc. --- is still causing additional damage to the > filesystem). This old smp box is generally good for my purposes, but it has long had a tendency to the occasional unexplained self-reset. It was one of these that sent the system down last evening. As I said in my original post, ext3 has always coped seamlessly with these before, but maybe last night the system was in a particularly vulnerable state. On the other hand maybe it is a new hdd problem. Someone has suggested by private email that I should run the diagnostics provided by smartmontools. I will do that at weekend when I have a little more time. > > However, files might be missing. > > It might be worthwhile to compare the files on your backup > hdd with your current filesystem, to see if you have any > missing files. Yes, I will do that. > It's also possible I suppose that data > blocks were actually corrupted, but that really depends on > how the inode table blocks got corrupted in the frist > place. > This is what really troubles me. If the problem is in a library or some seldom-used but essential utility then I am going to be in trouble when I am not expecting it. I really should bring my backup up-to-date in any case. If smartmontools don't reveal any hardware problems then the best strategy must be to substitute the backup for my current, drive do the update, then copy back to the the current drive. > > (b) Are there any other diagnostics I could run to > > confirm the integrity of my data? > > Aside from comparisons to backups, if you had been using > programs like cfv to calculate checksums of all of your > files, you could use them to check the data integrity of > your data files. > > On rpm-based systems, you can also do things like rpm -Va > to check the checksums of the installed files. This won't > check your data files, and will raise false positives > caused by config files that you have since modified, but > it might give you a hint that there is greater damage, or > put your mind at ease that things are more likely to be > OK. > I am running slack 9.1 with a vanilla 2.10 kernel and compile just about all of my applications locally. I guess I am pretty much on my own therefore. > Good luck, Thanks again, Geoff From theman at josephdwagner.info Wed Jan 19 16:15:18 2005 From: theman at josephdwagner.info (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:15:18 -0600 Subject: Policy after fsck fixes errors In-Reply-To: <20050119143752.42531623.capsthorne@yahoo.co.uk> Message-ID: <200501191614.j0JGErTT026179@mx3.redhat.com> > > It's also possible I suppose that data > > blocks were actually corrupted, but that really depends on > > how the inode table blocks got corrupted in the frist > > place. > > > > This is what really troubles me. If the problem is in a > library or some seldom-used but essential utility then I am > going to be in trouble when I am not expecting it. > > I really should bring my backup up-to-date in any case. > If smartmontools don't reveal any hardware problems then the > best strategy must be to substitute the backup for my > current, drive do the update, then copy back to the the > current drive. Did you take the time to check for bad blocks? From capsthorne at yahoo.co.uk Wed Jan 19 16:40:07 2005 From: capsthorne at yahoo.co.uk (Geoff) Date: Wed, 19 Jan 2005 16:40:07 +0000 Subject: Policy after fsck fixes errors In-Reply-To: <200501191620.j0JGK7vp008535@neutron.lan> References: <20050119143752.42531623.capsthorne@yahoo.co.uk> <200501191620.j0JGK7vp008535@neutron.lan> Message-ID: <20050119164007.16350377.capsthorne@yahoo.co.uk> On Wed, 19 Jan 2005 10:15:18 -0600 "Joseph D. Wagner" wrote: > Did you take the time to check for bad blocks? Thanks Joseph, Not yet - I recall that it is very time consuming and I needed to get to work this morning - but I will run it when I get the opportunity for a longer shutdown this evening. Geoff From evilninja at gmx.net Wed Jan 19 17:42:16 2005 From: evilninja at gmx.net (Christian) Date: Wed, 19 Jan 2005 18:42:16 +0100 (CET) Subject: Policy after fsck fixes errors In-Reply-To: <20050119143752.42531623.capsthorne@yahoo.co.uk> References: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> <20050119135653.GF15042@thunk.org> <20050119143752.42531623.capsthorne@yahoo.co.uk> Message-ID: <40630.195.126.66.126.1106156536.squirrel@housecafe.dyndns.org> On Wed, January 19, 2005 15:37, Geoff said: > > I am running slack 9.1 with a vanilla 2.10 kernel and you meant "kernel 2.6.10", right? otherwise it would be good to upgrade... lots of (ext3) improvements since then.... Christian. -- make bzImage, not war From capsthorne at yahoo.co.uk Wed Jan 19 18:06:16 2005 From: capsthorne at yahoo.co.uk (Geoff) Date: Wed, 19 Jan 2005 18:06:16 +0000 Subject: Policy after fsck fixes errors In-Reply-To: <40630.195.126.66.126.1106156536.squirrel@housecafe.dyndns.org> References: <20050119091637.088bfb5b.capsthorne@yahoo.co.uk> <20050119135653.GF15042@thunk.org> <20050119143752.42531623.capsthorne@yahoo.co.uk> <40630.195.126.66.126.1106156536.squirrel@housecafe.dyndns.org> Message-ID: <20050119180616.754ed441.capsthorne@yahoo.co.uk> On Wed, 19 Jan 2005 18:42:16 +0100 (CET) "Christian" wrote: > On Wed, January 19, 2005 15:37, Geoff said: > > > > I am running slack 9.1 with a vanilla 2.10 kernel and > > you meant "kernel 2.6.10", right? otherwise it would be > good to upgrade... lots of (ext3) improvements since > then.... Yes, 2.6.10, sorry for the slip (was typing at speed). Geoff From ext3 at solarwar.org Sun Jan 23 21:10:58 2005 From: ext3 at solarwar.org (Frederik) Date: Sun, 23 Jan 2005 22:10:58 +0100 (CET) Subject: ef2sck loops forever with re-allocation Message-ID: I hope someone is able to tell me wheter it is possible to rescue any data from my lvm disk. After adding a second disk, resizing, etc I made the super block sparse. Then problems surfaced. I tried both ef2sck v1.34 and v1.35 but they have the same result: Group descriptors look bad... trying backup blocks... Inode table for group 1519 is not in group. (block 7503623) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate? yes /dev/mapper/lvm_vg0-lv0 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes Relocating group 1519's inode table to 7503623... Restarting e2fsck from the beginning... Group descriptors look bad... trying backup blocks... Inode table for group 1519 is not in group. (block 7503623) WARNING: SEVERE DATA LOSS POSSIBLE. Relocate? yes /dev/mapper/lvm_vg0-lv0 was not cleanly unmounted, check forced. Pass 1: Checking inodes, blocks, and sizes ............... My last attempt was adding a loopback device in the lvm to create more space on the lvm device, but that didn't help. Any ideas on what to do next? Details of the two disks in lvm: --- Physical volume --- PV Name /dev/hde1 VG Name lvm_vg0 PV Size 189.91 GB / not usable 0 Allocatable yes (but full) PE Size (KByte) 4096 Total PE 48618 Free PE 0 Allocated PE 48618 --- Physical volume --- PV Name /dev/hdb1 VG Name lvm_vg0 PV Size 189.91 GB / not usable 0 Allocatable yes (but full) PE Size (KByte) 4096 Total PE 48618 Free PE 0 Allocated PE 48618 From toni at it-austria.net Mon Jan 17 22:24:11 2005 From: toni at it-austria.net (Toni Schmidbauer) Date: Mon, 17 Jan 2005 23:24:11 +0100 Subject: e2fsck 1.36-rc1 fixes fc3 resize2fs bug Message-ID: <20050117222411.GF20923@stderror.at> hi, just wanted to mention that using 1.36-rc1 fixes the following bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144771 thanks to benjamin scott for the hint, and theodore ts'o for fixing. building a source and binary rpm with the provided spec file works flawlessly under fc3 (just had to remove -rc1 from the archive name and Version: in the spec file). if you are replying to this mail, please cc me because i am not subscribed to the above lists. regards "guinea pig" toni -- Wer es einmal so weit gebracht hat, dass er nicht | toni at stderror dot at mehr irrt, der hat auch zu arbeiten aufgehoert | Toni Schmidbauer -- Max Planck | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From eric at lammerts.org Tue Jan 18 20:52:32 2005 From: eric at lammerts.org (Eric Lammerts) Date: Tue, 18 Jan 2005 15:52:32 -0500 (EST) Subject: [PATCH] ext3: commit superblock before panicking Message-ID: Hi, I have a problem with errors=panic on ext3. When a panic occurs, the error event is not recorded anywhere. So after the reboot, e2fsck doesn't kick in, the file system gets mounted again and the box panics again... Patch below moves the ERRORS_PANIC test down a bit so the journal is aborted before panic() is called. Eric Signed-off-by: Eric Lammerts --- linux-2.6.10/fs/ext3/super.c.orig 2005-01-18 15:07:47.673128436 -0500 +++ linux-2.6.10/fs/ext3/super.c 2005-01-18 15:43:55.311501654 -0500 @@ -143,9 +143,6 @@ if (sb->s_flags & MS_RDONLY) return; - if (test_opt (sb, ERRORS_PANIC)) - panic ("EXT3-fs (device %s): panic forced after error\n", - sb->s_id); if (test_opt (sb, ERRORS_RO)) { printk (KERN_CRIT "Remounting filesystem read-only\n"); sb->s_flags |= MS_RDONLY; @@ -156,6 +153,9 @@ if (journal) journal_abort(journal, -EIO); } + if (test_opt (sb, ERRORS_PANIC)) + panic ("EXT3-fs (device %s): panic forced after error\n", + sb->s_id); ext3_commit_super(sb, es, 1); } From barteet at mrl.ucsb.edu Thu Jan 27 22:22:47 2005 From: barteet at mrl.ucsb.edu (Jeffrey J. Barteet) Date: Thu, 27 Jan 2005 14:22:47 -0800 Subject: Does ext3 file system use a '.journal' file? Message-ID: <1106864567.41f969b77429f@webmail.mrl.ucsb.edu> Greetings, I recently cpio-ed some user directories onto a new ext3 partion. After putting this file server's partition into production, I noticed a .journal file in the root directory of the partition dated well before the creation of this partition. I think this .journal file was copied over from the old filesystem and I am concerned that I over-wrote this current filesystem's .journal file and this file system will explode the next time I reboot. I have also seen some non-definitive reference to ext3's journal being hidden. My questions: Does ext3 use a .journal file or is it hidden? If it DOES use a .journal file, can I rebuild it on the fly? i.e., while the file system is in production? I'm on the 2.6.10 kernel. Thanks, -jeffrey From theman at josephdwagner.info Fri Jan 28 00:32:14 2005 From: theman at josephdwagner.info (Joseph D. Wagner) Date: Thu, 27 Jan 2005 19:32:14 -0500 Subject: Does ext3 file system use a '.journal' file? Message-ID: > Does ext3 use a .journal file or is it hidden? Both. It's supposed to be hidden when mounted as EXT3, but you can see it when mounted as EXT2. > If it DOES use a .journal file, can I rebuild it on the fly? Yeah, just mount it as EXT2. Then delete the .journal file, and use tune2fs to rebuild a new one. You should then be able to unmount and remount as EXT3 just fine. Joseph D. Wagner From tytso at mit.edu Fri Jan 28 03:20:01 2005 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 27 Jan 2005 22:20:01 -0500 Subject: Does ext3 file system use a '.journal' file? In-Reply-To: References: Message-ID: <20050128032001.GB13290@thunk.org> On Thu, Jan 27, 2005 at 07:32:14PM -0500, Joseph D. Wagner wrote: > > Does ext3 use a .journal file or is it hidden? > > Both. It's supposed to be hidden when mounted as EXT3, but you can see > it when mounted as EXT2. Actually, that's not correct. Normally the journal is hidden; however, if you run tune2fs -j on a mounted filesystem, it can't create the hidden inode safely, so it creates an immutable file called .journal, and then sets the superblock to use the .journal file. If you run e2fsck on the filesystem while it is not mounted, it will automatically move the .journal inode to the reserved hidden journal inode, and then remove the .journal file. However, the root filesystem is normally going to be mounted when e2fsck is run, so this won't happen unless you run e2fsck from a rescue floppy. The real right thing would be to have the e2fsck of the root filesystem happen out of the initial ramdisk, but no distribution I know of does this at this point. (Note that for Debian unstable, if you are using an initial ramdisk, the simplest way to convert the root filesystem to use ext3 is to edit /etc/fstab so that the root filesystem type is ext3, and then reboot. The initial ramdisk script will then automatically run tune2fs -O has_journal on the root filesystem, and since it is not mounted, the journal will be created using the hidden inode. > > If it DOES use a .journal file, can I rebuild it on the fly? > > Yeah, just mount it as EXT2. Then delete the .journal file, and use > tune2fs to rebuild a new one. You should then be able to unmount and > remount as EXT3 just fine. Nope, that won't work. (Clearly, you didn't even bother to try this before dispensing advice...) First of all, if you try to delete the .journal file, it is marked as an immutable file, so you won't be able to do, even as root. If you manually clear the .journal file, and delete it, you will panic your system if it is mounted as ext3. If it is mounted as ext2, it will work, but the filesystem will be corrupted, and e2fsck will complain and downgrade the filesystem to ext2. If you try to use tune2fs to rebuild the filesystem before you run e2fsck, it will refuse, saying the filesystem already has a journal. In general, there shouldn't be a reason to rebuild the journal. Why do you want to in the first place? But if you want to change the size of the journal, you can use "tune2fs -O ^has_journal" to clear the journal safely and cleanly, and then "tune2fs -O has_journal" to recreate the journal, possibly with a different size. This has to be done while the filesystem is unmounted, so this may not count as "on the fly". If by "on the fly", you mean while the filesystem is mounted, the answer to that question is no. - Ted