blob: d531d1750bdf59805bed963d8f72f0da660aebad [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'ofdbba5c2000-02-08 23:16:51 +000051Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST)
52From: Alan Blanchard <alan@abraxas.to>
53To: tytso@MIT.EDU
54Subject: DEBUGFS - thanks and a feature idea
55Content-Type: TEXT/PLAIN; charset=US-ASCII
56
57Theodore:
58
59First, let me thank you for writing debugfs. Recently, my Linux box
60(RH 6.0, 400 MHz PIII, on a DSL line) was hacked into. The intruder did
61an "rm -Rf" on a 34 GB drive with about 5GB of data on it. I was able to
62restore essentially the entire thing with debugfs and a bit of C code and Perl.
63Actually, I could have done the entire thing with debugfs and Perl, but I
64thought it would be too slow.
65
66During this exercise, I noticed that one small feature was lacking that would
67have made my job a bit easier. The length of a deleted directory is
68reported as 0, hence debugfs won't dump the contents of the directory to a
69file using the "dump" command. The only thing that saved me was that the
70list of disk blocks is not zeroed out. I was able to dump the contents of the
71directories by using debugfs to get the relevant block numbers, then
72using dd to get the actual data.
73
74If debugfs had a feature where it ignored the size of a directory reported by
75the inode and instead just dumped all the blocks, it would have facilited
76things a bit. This seems like a very easy feature to add.
77
78Again, thanks for writing debugfs (and all the other Linux stuff you've written!).
79
80Cheers,
81Alan Blanchard
82alan@abraxas.to
83
84
85-------------------------------------------------------------------
86
87Date: Fri, 21 Jan 2000 14:07:12 -0800
88From: "H. Peter Anvin" <hpa@www.transmeta.com>
89Subject: mkfs -cc and fsck -c
90
Theodore Ts'ofdbba5c2000-02-08 23:16:51 +000091b) An option to mkfs to zero the partition. Yes, it can be done with
92dd, but it would be a nicer way of doing it.
93
Theodore Ts'o19178752000-02-11 15:55:07 +000094------------------------------------------------------------------
95
96Add support for in ext2fs_block_iterate() for a returning the
97compressed flag blocks to block_iterate. Change default to not return
98EXT2_COMPRESSED_BLKADDR. Change e2fsck to pass this flag in.
99
100(The old compression patches did this by default all the time, which
101is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR
102flagword.
103
104------------------------------------------------------------
105
106E2fsck should offer to clear all the blocks in an indirect block, not
107the entire inode, so there's better recovery for when an indirect
108block gets trashed.
109
110
Theodore Ts'occ73e042000-04-06 23:05:32 +0000111-------------------------------------------------------------
112
113From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM>
114Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET)
115
116During my experiments on the broken system, I noticed the following in
117the badblocks program (which I'm aware is not designed for IDE drives)
118- I'd probably have already fixed them if my home system was up :(
119
120* the syntax summary documents 2nd arg as blocks_count, which should
121probably read something like end_count.
122
123* testing past end of device is not detected, and lists those blocks
124as bad, whereas they simply do not exist.
125
126
127I think I'll probably add a "max count" option to findsuper(8), so
128that I do not have to wait for the whole disk to be scanned when the
129system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ]
130and friends appear to be absolutely ignored.
131
132
133Somewhat unrelated, I just noticed the
134http://web.mit.edu/tytso/www/linux/ext2.html could be updated:
135
Theodore Ts'occ73e042000-04-06 23:05:32 +0000136- could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just
137 release 0.03 snapshot)
138
139----------------------------------------------------------------
140
141Return-Path: <tytso@MIT.EDU>
142Date: Thu, 10 Feb 2000 13:20:14 -0500
143From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
144To: R.E.Wolff@BitWizard.nl
145In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET),
146 <200002100746.IAA24573@cave.bitwizard.nl>
147Subject: Re: e2fsck request for enhancement.
148Phone: (781) 391-3464
149
150 Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET)
151 From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
152
153 Lately, while trying to recover a broken disk, my system froze (twice,
154 until I tried something else) while copying the disk.
155
156 So I had a file of about 50Mb that was growing frantically at the
157 moment of the crash.
158
159 e2fsck, then finds an indirect block that is completely bogus. It
160 starts by asking me if it's ok to clear a few of the referenced
161 blocks. I say yes. Then it comes to the conclusion:
162
163 too many invalid blocks. Clear inode?
164
165 and then I get the option to delete the whole file. Not to truncate
166 the file to a "working" size.
167
168
169 I'd MUCH rather have e2fsck say something like:
170
171 inode 1234 references an invalid block 134345454. Hmm.
172 inode 1234 references 567 out of 50176 invalid blocks,
173 all near the end. Truncate file to 49152 blocks?
174
175 Here you can see that of the 1024 blocks near the end of the file,
176 only 567 were detected as invalid. However now 48Mb of the file will
177 be recovered, instead of thrown away.
178
179That's a good point. Actually, the right thing is for e2fsck to offer
180to clear all of the bad blocks in a particular indirect block. I don't
181know how hard it would be to do that, but I'll put it on my e2fsprogs
182TODO list.
183
184 - Ted
185
Theodore Ts'o0cf43d82001-05-11 05:12:07 +0000186---------------------------------------------------------------
Theodore Ts'o151c86a2003-07-25 07:03:00 -0400187From e2fsprogs Debian TODO file as of 1.10-13.
188
189* Maybe make -dbg packages. Look at how others do it.
190
Theodore Ts'o6d037b32004-03-02 11:18:21 -0500191---------------------------------------------------------------
192
193Add --lba option to debian icheck command, and have ways of making it
194easier to translate LBA to filesystem block numbers.
Theodore Ts'oea1e8f42005-01-19 18:18:44 -0500195
196-------------------------------------------------------
197
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500198
199
200List of projects for e2fsprogs:
201
202
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002031) Make debugfs's "ncheck <inode>" command list all of the pathnames
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500204to an inode, not just only the first link to the inode which is found.
Theodore Ts'o69e59c22006-05-13 09:28:04 -0400205(A good "intro to libext2fs programming interfaces project)
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500206
207 Difficulty: Low Priority: Low
208
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002092) Use a code coverage tool such as Rational's PureCoverage to see
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500210what kind of code coverage we have for e2fsck, and try to add test
211cases to increase the code coverage for e2fsck.
212
213 Difficulty: Medium Priorty: Low
214
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002153) Use a code coverage tool such as Rational's PureCoverage to see
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500216what kind of code coverage we have for resize2fs, and try to add test
217cases to increase the code coverage for resize2fs.
218
219 Difficulty: Medium Priorty: Medium
220
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002214) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500222layers on top of an existing I/O manager which provides copy-on-write
223functionality. This COW I/O manager takes will take two open I/O
224managers, call them "base" and "changed". The "base" I/O manager is
225opened read/only, so any changes are written instead to the "changed"
226I/O manager, in a compact, non-sparse format containing the intended
227modification to the "base" filesystem.
228
229This will allow resize2fs to figure out what changes need to made to
230extend a filesystem, or expand the size of inodes in the inode table,
231and the changes can be pushed the filesystem in one fell swoop. (If
232the system crashes; the program which runs the "changed" file can be
233re-run, much like a journal replay. My assumption is that the COW
234file will contain the filesystem UUID in a the COW superblock, and the
235COW file will be stored in some place such as /var/state/e2fsprogs,
236with an init.d file to automate the replay so we can recover cleanly
237from a crash during the resize2fs process.)
238
239 Difficulty: Medium Priority: Medium
240
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002415) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500242layers on top of an existing I/O manager which provides an "undo"
243functionality. This undo I/O manager takes will take two open I/O
244managers, call them "base" and "undo". The "base" I/O manager is be
245opened read/write, and when any writes are sent to the I/O manager,
246the I/O manager will check the "undo" I/O manager, using a file format
247identical to the one found in (5) above.
248
249This is useful for allowing e2fsck to create an "undo" file, which
250would make things like "e2fsck -y" much safer.
251
252 Difficulty: Low (once 5 is done) Priority: Low
253
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002546) Modify resize2fs so that it can relocate and reorganize the
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500255filesystem in the following ways: (1) increase the inode size, so that
256an existing filesystem can use the EA-in-inode kernel patch, (2)
257reserve blocks in the resize inode to allow for on-line resizing. Use
258the COW I/O manager described in (5) in order to provide robustness in
259case of a crash during the resize/reorganization operation.
260
261 Difficulty: High Priority: Medium
262
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002637) Review the EA-in-inode patches to e2fsck for correctness/code
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500264cleanliness. (I will probably have to do this myself -- Ted)
265
266 Difficulty: High Priorty: Medium
267
Theodore Ts'o69e59c22006-05-13 09:28:04 -04002688) Add support for extent maps to e2fsprogs. I need to review the
Theodore Ts'o19a868e2005-03-01 17:15:33 -0500269extent maps first/in parallel.
270
271 Difficulty: High Priority: Medium
Theodore Ts'o5e916142005-04-14 17:10:14 -0400272
273----------------------------------
274
275Need to deal with the case where the resize inode overlaps with the
276bad blocks inode.
277