]>
Commit | Line | Data |
---|---|---|
abdf84f3 | 1 | Need to process the bad block inode *before* doing the inode scan. |
c4c30b20 TT |
2 | |
3 | Also check to see if the first block of the inode table is not on the | |
4 | bad block scan, and fix that. We need to check for an inaccurate | |
5 | blocks, and fix them before we start doing anything else with the | |
6 | filesystem! | |
7 | ||
8 | --------------------------------------------------- | |
c461e16a TT |
9 | User request: |
10 | ||
11 | BTW: 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 | |
e2e69ba4 TT |
15 | by hand :- |
16 | ||
17 | ------------------------------------------ | |
18 | ||
19 | Add a "answer Yes always to this class of question" response. | |
20 | ||
21 | ---------------------------------- | |
22 | ||
23 | ext2fs_flush() should return a different error message for primary | |
24 | versus backup superblock flushing, so that mke2fs can print an | |
25 | appropriate error message. | |
26 | ||
e2e69ba4 | 27 | --------------------------------- |
e2e69ba4 TT |
28 | Date: Mon, 08 Mar 1999 21:46:14 +0100 |
29 | From: Sergio Polini <s.polini@mclink.it> | |
30 | ||
31 | ||
055866d8 | 32 | I'm reading the source code of e2fsck 1.14. |
e2e69ba4 TT |
33 | In pass2.c, lines 352-357, I read: |
34 | ||
35 | if ((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 | ||
42 | I think that I'll never see any messages about too long filenames, | |
43 | because "whatever & 0xFF" can never be "> 0xFF". | |
44 | Am I wrong? | |
45 | -------------------------------------- | |
46 | ||
e2a99be6 | 47 | Add chmod command to debugfs. |
e2e69ba4 | 48 | |
8a31ffef TT |
49 | ------------------------------------------ |
50 | ||
fdbba5c2 TT |
51 | Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST) |
52 | From: Alan Blanchard <alan@abraxas.to> | |
53 | To: tytso@MIT.EDU | |
54 | Subject: DEBUGFS - thanks and a feature idea | |
55 | Content-Type: TEXT/PLAIN; charset=US-ASCII | |
56 | ||
57 | Theodore: | |
58 | ||
59 | First, 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 | |
61 | an "rm -Rf" on a 34 GB drive with about 5GB of data on it. I was able to | |
62 | restore essentially the entire thing with debugfs and a bit of C code and Perl. | |
63 | Actually, I could have done the entire thing with debugfs and Perl, but I | |
64 | thought it would be too slow. | |
65 | ||
66 | During this exercise, I noticed that one small feature was lacking that would | |
67 | have made my job a bit easier. The length of a deleted directory is | |
68 | reported as 0, hence debugfs won't dump the contents of the directory to a | |
69 | file using the "dump" command. The only thing that saved me was that the | |
70 | list of disk blocks is not zeroed out. I was able to dump the contents of the | |
71 | directories by using debugfs to get the relevant block numbers, then | |
72 | using dd to get the actual data. | |
73 | ||
74 | If debugfs had a feature where it ignored the size of a directory reported by | |
055866d8 | 75 | the inode and instead just dumped all the blocks, it would have facilitated |
fdbba5c2 TT |
76 | things a bit. This seems like a very easy feature to add. |
77 | ||
78 | Again, thanks for writing debugfs (and all the other Linux stuff you've written!). | |
79 | ||
80 | Cheers, | |
81 | Alan Blanchard | |
82 | alan@abraxas.to | |
83 | ||
84 | ||
85 | ------------------------------------------------------------------- | |
86 | ||
87 | Date: Fri, 21 Jan 2000 14:07:12 -0800 | |
88 | From: "H. Peter Anvin" <hpa@www.transmeta.com> | |
89 | Subject: mkfs -cc and fsck -c | |
90 | ||
fdbba5c2 TT |
91 | b) An option to mkfs to zero the partition. Yes, it can be done with |
92 | dd, but it would be a nicer way of doing it. | |
93 | ||
1917875f TT |
94 | ------------------------------------------------------------------ |
95 | ||
96 | Add support for in ext2fs_block_iterate() for a returning the | |
97 | compressed flag blocks to block_iterate. Change default to not return | |
98 | EXT2_COMPRESSED_BLKADDR. Change e2fsck to pass this flag in. | |
99 | ||
100 | (The old compression patches did this by default all the time, which | |
101 | is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR | |
102 | flagword. | |
103 | ||
104 | ------------------------------------------------------------ | |
105 | ||
106 | E2fsck should offer to clear all the blocks in an indirect block, not | |
107 | the entire inode, so there's better recovery for when an indirect | |
108 | block gets trashed. | |
109 | ||
110 | ||
cc73e040 TT |
111 | ------------------------------------------------------------- |
112 | ||
113 | From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM> | |
114 | Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET) | |
115 | ||
116 | During my experiments on the broken system, I noticed the following in | |
117 | the 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 | |
121 | probably read something like end_count. | |
122 | ||
123 | * testing past end of device is not detected, and lists those blocks | |
124 | as bad, whereas they simply do not exist. | |
125 | ||
126 | ||
127 | I think I'll probably add a "max count" option to findsuper(8), so | |
128 | that I do not have to wait for the whole disk to be scanned when the | |
129 | system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ] | |
130 | and friends appear to be absolutely ignored. | |
131 | ||
132 | ||
133 | Somewhat unrelated, I just noticed the | |
134 | http://web.mit.edu/tytso/www/linux/ext2.html could be updated: | |
135 | ||
cc73e040 TT |
136 | - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just |
137 | release 0.03 snapshot) | |
138 | ||
139 | ---------------------------------------------------------------- | |
140 | ||
141 | Return-Path: <tytso@MIT.EDU> | |
142 | Date: Thu, 10 Feb 2000 13:20:14 -0500 | |
143 | From: "Theodore Y. Ts'o" <tytso@MIT.EDU> | |
144 | To: R.E.Wolff@BitWizard.nl | |
145 | In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET), | |
146 | <200002100746.IAA24573@cave.bitwizard.nl> | |
147 | Subject: Re: e2fsck request for enhancement. | |
148 | Phone: (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 | ||
179 | That's a good point. Actually, the right thing is for e2fsck to offer | |
180 | to clear all of the bad blocks in a particular indirect block. I don't | |
181 | know how hard it would be to do that, but I'll put it on my e2fsprogs | |
182 | TODO list. | |
183 | ||
184 | - Ted | |
185 | ||
0cf43d8b | 186 | --------------------------------------------------------------- |
151c86ab TT |
187 | From e2fsprogs Debian TODO file as of 1.10-13. |
188 | ||
189 | * Maybe make -dbg packages. Look at how others do it. | |
190 | ||
6d037b37 TT |
191 | --------------------------------------------------------------- |
192 | ||
193 | Add --lba option to debian icheck command, and have ways of making it | |
194 | easier to translate LBA to filesystem block numbers. | |
ea1e8f47 TT |
195 | |
196 | ------------------------------------------------------- | |
197 | ||
19a868e0 TT |
198 | |
199 | ||
200 | List of projects for e2fsprogs: | |
201 | ||
202 | ||
69e59c22 | 203 | 1) Make debugfs's "ncheck <inode>" command list all of the pathnames |
19a868e0 | 204 | to an inode, not just only the first link to the inode which is found. |
69e59c22 | 205 | (A good "intro to libext2fs programming interfaces project) |
19a868e0 TT |
206 | |
207 | Difficulty: Low Priority: Low | |
208 | ||
69e59c22 | 209 | 2) Use a code coverage tool such as Rational's PureCoverage to see |
19a868e0 TT |
210 | what kind of code coverage we have for e2fsck, and try to add test |
211 | cases to increase the code coverage for e2fsck. | |
212 | ||
213 | Difficulty: Medium Priorty: Low | |
214 | ||
69e59c22 | 215 | 3) Use a code coverage tool such as Rational's PureCoverage to see |
19a868e0 TT |
216 | what kind of code coverage we have for resize2fs, and try to add test |
217 | cases to increase the code coverage for resize2fs. | |
218 | ||
219 | Difficulty: Medium Priorty: Medium | |
220 | ||
69e59c22 | 221 | 4) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which |
19a868e0 TT |
222 | layers on top of an existing I/O manager which provides copy-on-write |
223 | functionality. This COW I/O manager takes will take two open I/O | |
224 | managers, call them "base" and "changed". The "base" I/O manager is | |
225 | opened read/only, so any changes are written instead to the "changed" | |
226 | I/O manager, in a compact, non-sparse format containing the intended | |
227 | modification to the "base" filesystem. | |
228 | ||
229 | This will allow resize2fs to figure out what changes need to made to | |
230 | extend a filesystem, or expand the size of inodes in the inode table, | |
231 | and the changes can be pushed the filesystem in one fell swoop. (If | |
232 | the system crashes; the program which runs the "changed" file can be | |
233 | re-run, much like a journal replay. My assumption is that the COW | |
234 | file will contain the filesystem UUID in a the COW superblock, and the | |
235 | COW file will be stored in some place such as /var/state/e2fsprogs, | |
236 | with an init.d file to automate the replay so we can recover cleanly | |
237 | from a crash during the resize2fs process.) | |
238 | ||
239 | Difficulty: Medium Priority: Medium | |
240 | ||
69e59c22 | 241 | 5) Create a new I/O manager (i.e., test_io.c, unix_io.c, et.al.) which |
19a868e0 TT |
242 | layers on top of an existing I/O manager which provides an "undo" |
243 | functionality. This undo I/O manager takes will take two open I/O | |
244 | managers, call them "base" and "undo". The "base" I/O manager is be | |
245 | opened read/write, and when any writes are sent to the I/O manager, | |
246 | the I/O manager will check the "undo" I/O manager, using a file format | |
247 | identical to the one found in (5) above. | |
248 | ||
249 | This is useful for allowing e2fsck to create an "undo" file, which | |
250 | would make things like "e2fsck -y" much safer. | |
251 | ||
252 | Difficulty: Low (once 5 is done) Priority: Low | |
253 | ||
69e59c22 | 254 | 6) Modify resize2fs so that it can relocate and reorganize the |
19a868e0 TT |
255 | filesystem in the following ways: (1) increase the inode size, so that |
256 | an existing filesystem can use the EA-in-inode kernel patch, (2) | |
257 | reserve blocks in the resize inode to allow for on-line resizing. Use | |
258 | the COW I/O manager described in (5) in order to provide robustness in | |
259 | case of a crash during the resize/reorganization operation. | |
260 | ||
261 | Difficulty: High Priority: Medium | |
262 | ||
69e59c22 | 263 | 7) Review the EA-in-inode patches to e2fsck for correctness/code |
19a868e0 TT |
264 | cleanliness. (I will probably have to do this myself -- Ted) |
265 | ||
266 | Difficulty: High Priorty: Medium | |
267 | ||
69e59c22 | 268 | 8) Add support for extent maps to e2fsprogs. I need to review the |
19a868e0 TT |
269 | extent maps first/in parallel. |
270 | ||
271 | Difficulty: High Priority: Medium | |
5e916143 TT |
272 | |
273 | ---------------------------------- | |
274 | ||
275 | Need to deal with the case where the resize inode overlaps with the | |
276 | bad blocks inode. | |
277 |