3 BTW: Could you please add some sort of deleted and possibly corrupted file
4 and inode list to e2fsck report. There should be filenames deleted
5 from directory inodes, files with duplicate blocks e.t.c.
6 It's pretty annoying to filter this information from e2fsck output
9 ------------------------------------------
11 Add a "answer Yes always to this class of question" response.
13 ----------------------------------
15 ext2fs_flush() should return a different error message for primary
16 versus backup superblock flushing, so that mke2fs can print an
17 appropriate error message.
19 ---------------------------------
20 Date: Mon, 08 Mar 1999 21:46:14 +0100
21 From: Sergio Polini <s.polini@mclink.it>
24 I'm reading the sorce code of e2fsck 1.14.
25 In pass2.c, lines 352-357, I read:
27 if ((dirent->name_len & 0xFF) > EXT2_NAME_LEN) {
28 if (fix_problem(ctx, PR_2_FILENAME_LONG, &cd->pctx)) {
29 dirent->name_len = EXT2_NAME_LEN;
34 I think that I'll never see any messages about too long filenames,
35 because "whatever & 0xFF" can never be "> 0xFF".
37 --------------------------------------
39 Add chmod command to debugfs.
41 ------------------------------------------
43 fix up get_backup_sb, so that it doesn't choose something bogus if
44 fs->super->.... is ridiculous
46 ----------------------------------
48 Maybe a bug in debugfs v.1.14:
49 if a file has more than one hardlink, only the first filename is shown when
53 ------------------------------------
55 Add a filesystem creation date to the superblock
57 -----------------------------------
58 Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST)
59 From: Alan Blanchard <alan@abraxas.to>
61 Subject: DEBUGFS - thanks and a feature idea
62 Content-Type: TEXT/PLAIN; charset=US-ASCII
66 First, let me thank you for writing debugfs. Recently, my Linux box
67 (RH 6.0, 400 MHz PIII, on a DSL line) was hacked into. The intruder did
68 an "rm -Rf" on a 34 GB drive with about 5GB of data on it. I was able to
69 restore essentially the entire thing with debugfs and a bit of C code and Perl.
70 Actually, I could have done the entire thing with debugfs and Perl, but I
71 thought it would be too slow.
73 During this exercise, I noticed that one small feature was lacking that would
74 have made my job a bit easier. The length of a deleted directory is
75 reported as 0, hence debugfs won't dump the contents of the directory to a
76 file using the "dump" command. The only thing that saved me was that the
77 list of disk blocks is not zeroed out. I was able to dump the contents of the
78 directories by using debugfs to get the relevant block numbers, then
79 using dd to get the actual data.
81 If debugfs had a feature where it ignored the size of a directory reported by
82 the inode and instead just dumped all the blocks, it would have facilited
83 things a bit. This seems like a very easy feature to add.
85 Again, thanks for writing debugfs (and all the other Linux stuff you've written!).
92 -------------------------------------------------------------------
94 Date: Fri, 21 Jan 2000 14:07:12 -0800
95 From: "H. Peter Anvin" <hpa@www.transmeta.com>
96 Subject: mkfs -cc and fsck -c
98 a) An option to mkfs to run badblocks in read/write mode. The
99 filesystem is blank, so this is the perfect time to run the read/write
102 b) An option to mkfs to zero the partition. Yes, it can be done with
103 dd, but it would be a nicer way of doing it.
105 ------------------------------------------------------------------
107 Add support for in ext2fs_block_iterate() for a returning the
108 compressed flag blocks to block_iterate. Change default to not return
109 EXT2_COMPRESSED_BLKADDR. Change e2fsck to pass this flag in.
111 (The old compression patches did this by default all the time, which
112 is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR
115 ------------------------------------------------------------
117 E2fsck should offer to clear all the blocks in an indirect block, not
118 the entire inode, so there's better recovery for when an indirect
122 -------------------------------------------------------------
124 From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM>
125 Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET)
127 During my experiments on the broken system, I noticed the following in
128 the badblocks program (which I'm aware is not designed for IDE drives)
129 - I'd probably have already fixed them if my home system was up :(
131 * the syntax summary documents 2nd arg as blocks_count, which should
132 probably read something like end_count.
134 * testing past end of device is not detected, and lists those blocks
135 as bad, whereas they simply do not exist.
138 I think I'll probably add a "max count" option to findsuper(8), so
139 that I do not have to wait for the whole disk to be scanned when the
140 system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ]
141 and friends appear to be absolutely ignored.
144 Somewhat unrelated, I just noticed the
145 http://web.mit.edu/tytso/www/linux/ext2.html could be updated:
147 - mentions 1.17 as new :)
148 - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just
149 release 0.03 snapshot)
151 ----------------------------------------------------------------
153 Return-Path: <tytso@MIT.EDU>
154 Date: Thu, 10 Feb 2000 13:20:14 -0500
155 From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
156 To: R.E.Wolff@BitWizard.nl
157 In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET),
158 <200002100746.IAA24573@cave.bitwizard.nl>
159 Subject: Re: e2fsck request for enhancement.
160 Phone: (781) 391-3464
162 Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET)
163 From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
165 Lately, while trying to recover a broken disk, my system froze (twice,
166 until I tried something else) while copying the disk.
168 So I had a file of about 50Mb that was growing frantically at the
171 e2fsck, then finds an indirect block that is completely bogus. It
172 starts by asking me if it's ok to clear a few of the referenced
173 blocks. I say yes. Then it comes to the conclusion:
175 too many invalid blocks. Clear inode?
177 and then I get the option to delete the whole file. Not to truncate
178 the file to a "working" size.
181 I'd MUCH rather have e2fsck say something like:
183 inode 1234 references an invalid block 134345454. Hmm.
184 inode 1234 references 567 out of 50176 invalid blocks,
185 all near the end. Truncate file to 49152 blocks?
187 Here you can see that of the 1024 blocks near the end of the file,
188 only 567 were detected as invalid. However now 48Mb of the file will
189 be recovered, instead of thrown away.
191 That's a good point. Actually, the right thing is for e2fsck to offer
192 to clear all of the bad blocks in a particular indirect block. I don't
193 know how hard it would be to do that, but I'll put it on my e2fsprogs
198 ----------------------------------------------------------------