blob: 3339705382beb9b7d0f70a5a1f087724f9dc45a5 [file] [log] [blame]
Theodore Ts'oabdf84f2004-03-20 16:54:15 -05001Need to process the bad block inode *before* doing the inode scan.
Theodore Ts'oc4c30b22003-12-07 02:16:43 -05002
3Also check to see if the first block of the inode table is not on the
4bad block scan, and fix that. We need to check for an inaccurate
5blocks, and fix them before we start doing anything else with the
6filesystem!
7
8---------------------------------------------------
Theodore Ts'oc461e161999-01-12 23:40:01 +00009User request:
10
11BTW: Could you please add some sort of deleted and possibly corrupted file
12 and inode list to e2fsck report. There should be filenames deleted
13 from directory inodes, files with duplicate blocks e.t.c.
14 It's pretty annoying to filter this information from e2fsck output
Theodore Ts'oe2e69ba1999-06-18 01:13:31 +000015 by hand :-
16
17------------------------------------------
18
19Add a "answer Yes always to this class of question" response.
20
21----------------------------------
22
23ext2fs_flush() should return a different error message for primary
24versus backup superblock flushing, so that mke2fs can print an
25appropriate error message.
26
Theodore Ts'oe2e69ba1999-06-18 01:13:31 +000027---------------------------------
Theodore Ts'oe2e69ba1999-06-18 01:13:31 +000028Date: Mon, 08 Mar 1999 21:46:14 +0100
29From: Sergio Polini <s.polini@mclink.it>
30
31
32I'm reading the sorce code of e2fsck 1.14.
33In pass2.c, lines 352-357, I read:
34
35if ((dirent->name_len & 0xFF) > EXT2_NAME_LEN) {
36 if (fix_problem(ctx, PR_2_FILENAME_LONG, &cd->pctx)) {
37 dirent->name_len = EXT2_NAME_LEN;
38 dir_modified++;
39 }
40}
41
42I think that I'll never see any messages about too long filenames,
43because "whatever & 0xFF" can never be "> 0xFF".
44Am I wrong?
45--------------------------------------
46
Theodore Ts'oe2a99be1999-07-19 15:48:08 +000047Add chmod command to debugfs.
Theodore Ts'oe2e69ba1999-06-18 01:13:31 +000048
Theodore Ts'o8a31ffe1999-10-23 03:33:15 +000049------------------------------------------
50
Theodore Ts'o24ded091999-11-10 15:56:16 +000051Maybe a bug in debugfs v.1.14:
52if a file has more than one hardlink, only the first filename is shown when
53using command
54 ncheck <inode>
55
56------------------------------------
Theodore Ts'ofdbba5c2000-02-08 23:16:51 +000057
58Add a filesystem creation date to the superblock
59
60-----------------------------------
61Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST)
62From: Alan Blanchard <alan@abraxas.to>
63To: tytso@MIT.EDU
64Subject: DEBUGFS - thanks and a feature idea
65Content-Type: TEXT/PLAIN; charset=US-ASCII
66
67Theodore:
68
69First, let me thank you for writing debugfs. Recently, my Linux box
70(RH 6.0, 400 MHz PIII, on a DSL line) was hacked into. The intruder did
71an "rm -Rf" on a 34 GB drive with about 5GB of data on it. I was able to
72restore essentially the entire thing with debugfs and a bit of C code and Perl.
73Actually, I could have done the entire thing with debugfs and Perl, but I
74thought it would be too slow.
75
76During this exercise, I noticed that one small feature was lacking that would
77have made my job a bit easier. The length of a deleted directory is
78reported as 0, hence debugfs won't dump the contents of the directory to a
79file using the "dump" command. The only thing that saved me was that the
80list of disk blocks is not zeroed out. I was able to dump the contents of the
81directories by using debugfs to get the relevant block numbers, then
82using dd to get the actual data.
83
84If debugfs had a feature where it ignored the size of a directory reported by
85the inode and instead just dumped all the blocks, it would have facilited
86things a bit. This seems like a very easy feature to add.
87
88Again, thanks for writing debugfs (and all the other Linux stuff you've written!).
89
90Cheers,
91Alan Blanchard
92alan@abraxas.to
93
94
95-------------------------------------------------------------------
96
97Date: Fri, 21 Jan 2000 14:07:12 -0800
98From: "H. Peter Anvin" <hpa@www.transmeta.com>
99Subject: mkfs -cc and fsck -c
100
Theodore Ts'ofdbba5c2000-02-08 23:16:51 +0000101b) An option to mkfs to zero the partition. Yes, it can be done with
102dd, but it would be a nicer way of doing it.
103
Theodore Ts'o19178752000-02-11 15:55:07 +0000104------------------------------------------------------------------
105
106Add support for in ext2fs_block_iterate() for a returning the
107compressed flag blocks to block_iterate. Change default to not return
108EXT2_COMPRESSED_BLKADDR. Change e2fsck to pass this flag in.
109
110(The old compression patches did this by default all the time, which
111is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR
112flagword.
113
114------------------------------------------------------------
115
116E2fsck should offer to clear all the blocks in an indirect block, not
117the entire inode, so there's better recovery for when an indirect
118block gets trashed.
119
120
Theodore Ts'occ73e042000-04-06 23:05:32 +0000121-------------------------------------------------------------
122
123From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM>
124Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET)
125
126During my experiments on the broken system, I noticed the following in
127the badblocks program (which I'm aware is not designed for IDE drives)
128- I'd probably have already fixed them if my home system was up :(
129
130* the syntax summary documents 2nd arg as blocks_count, which should
131probably read something like end_count.
132
133* testing past end of device is not detected, and lists those blocks
134as bad, whereas they simply do not exist.
135
136
137I think I'll probably add a "max count" option to findsuper(8), so
138that I do not have to wait for the whole disk to be scanned when the
139system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ]
140and friends appear to be absolutely ignored.
141
142
143Somewhat unrelated, I just noticed the
144http://web.mit.edu/tytso/www/linux/ext2.html could be updated:
145
Theodore Ts'occ73e042000-04-06 23:05:32 +0000146- could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just
147 release 0.03 snapshot)
148
149----------------------------------------------------------------
150
151Return-Path: <tytso@MIT.EDU>
152Date: Thu, 10 Feb 2000 13:20:14 -0500
153From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
154To: R.E.Wolff@BitWizard.nl
155In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET),
156 <200002100746.IAA24573@cave.bitwizard.nl>
157Subject: Re: e2fsck request for enhancement.
158Phone: (781) 391-3464
159
160 Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET)
161 From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
162
163 Lately, while trying to recover a broken disk, my system froze (twice,
164 until I tried something else) while copying the disk.
165
166 So I had a file of about 50Mb that was growing frantically at the
167 moment of the crash.
168
169 e2fsck, then finds an indirect block that is completely bogus. It
170 starts by asking me if it's ok to clear a few of the referenced
171 blocks. I say yes. Then it comes to the conclusion:
172
173 too many invalid blocks. Clear inode?
174
175 and then I get the option to delete the whole file. Not to truncate
176 the file to a "working" size.
177
178
179 I'd MUCH rather have e2fsck say something like:
180
181 inode 1234 references an invalid block 134345454. Hmm.
182 inode 1234 references 567 out of 50176 invalid blocks,
183 all near the end. Truncate file to 49152 blocks?
184
185 Here you can see that of the 1024 blocks near the end of the file,
186 only 567 were detected as invalid. However now 48Mb of the file will
187 be recovered, instead of thrown away.
188
189That's a good point. Actually, the right thing is for e2fsck to offer
190to clear all of the bad blocks in a particular indirect block. I don't
191know how hard it would be to do that, but I'll put it on my e2fsprogs
192TODO list.
193
194 - Ted
195
Theodore Ts'o0cf43d82001-05-11 05:12:07 +0000196---------------------------------------------------------------
Theodore Ts'o151c86a2003-07-25 07:03:00 -0400197From e2fsprogs Debian TODO file as of 1.10-13.
198
199* Maybe make -dbg packages. Look at how others do it.
200
Theodore Ts'o6d037b32004-03-02 11:18:21 -0500201---------------------------------------------------------------
202
203Add --lba option to debian icheck command, and have ways of making it
204easier to translate LBA to filesystem block numbers.