]>
Commit | Line | Data |
---|---|---|
c461e16a TT |
1 | User request: |
2 | ||
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 | |
e2e69ba4 TT |
7 | by hand :- |
8 | ||
9 | ------------------------------------------ | |
10 | ||
11 | Add a "answer Yes always to this class of question" response. | |
12 | ||
13 | ---------------------------------- | |
14 | ||
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. | |
18 | ||
e2e69ba4 | 19 | --------------------------------- |
e2e69ba4 TT |
20 | Date: Mon, 08 Mar 1999 21:46:14 +0100 |
21 | From: Sergio Polini <s.polini@mclink.it> | |
22 | ||
23 | ||
24 | I'm reading the sorce code of e2fsck 1.14. | |
25 | In pass2.c, lines 352-357, I read: | |
26 | ||
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; | |
30 | dir_modified++; | |
31 | } | |
32 | } | |
33 | ||
34 | I think that I'll never see any messages about too long filenames, | |
35 | because "whatever & 0xFF" can never be "> 0xFF". | |
36 | Am I wrong? | |
37 | -------------------------------------- | |
38 | ||
e2a99be6 | 39 | Add chmod command to debugfs. |
e2e69ba4 | 40 | |
8a31ffef TT |
41 | ------------------------------------------ |
42 | ||
43 | fix up get_backup_sb, so that it doesn't choose something bogus if | |
44 | fs->super->.... is ridiculous | |
45 | ||
24ded091 TT |
46 | ---------------------------------- |
47 | ||
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 | |
50 | using command | |
51 | ncheck <inode> | |
52 | ||
53 | ------------------------------------ | |
fdbba5c2 TT |
54 | |
55 | Add a filesystem creation date to the superblock | |
56 | ||
57 | ----------------------------------- | |
58 | Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST) | |
59 | From: Alan Blanchard <alan@abraxas.to> | |
60 | To: tytso@MIT.EDU | |
61 | Subject: DEBUGFS - thanks and a feature idea | |
62 | Content-Type: TEXT/PLAIN; charset=US-ASCII | |
63 | ||
64 | Theodore: | |
65 | ||
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. | |
72 | ||
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. | |
80 | ||
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. | |
84 | ||
85 | Again, thanks for writing debugfs (and all the other Linux stuff you've written!). | |
86 | ||
87 | Cheers, | |
88 | Alan Blanchard | |
89 | alan@abraxas.to | |
90 | ||
91 | ||
92 | ------------------------------------------------------------------- | |
93 | ||
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 | |
97 | ||
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 | |
100 | test. | |
101 | ||
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. | |
104 | ||
1917875f TT |
105 | ------------------------------------------------------------------ |
106 | ||
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. | |
110 | ||
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 | |
113 | flagword. | |
114 | ||
115 | ------------------------------------------------------------ | |
116 | ||
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 | |
119 | block gets trashed. | |
120 | ||
121 | ||
cc73e040 TT |
122 | ------------------------------------------------------------- |
123 | ||
124 | From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM> | |
125 | Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET) | |
126 | ||
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 :( | |
130 | ||
131 | * the syntax summary documents 2nd arg as blocks_count, which should | |
132 | probably read something like end_count. | |
133 | ||
134 | * testing past end of device is not detected, and lists those blocks | |
135 | as bad, whereas they simply do not exist. | |
136 | ||
137 | ||
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. | |
142 | ||
143 | ||
144 | Somewhat unrelated, I just noticed the | |
145 | http://web.mit.edu/tytso/www/linux/ext2.html could be updated: | |
146 | ||
147 | - mentions 1.17 as new :) | |
148 | - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just | |
149 | release 0.03 snapshot) | |
150 | ||
151 | ---------------------------------------------------------------- | |
152 | ||
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 | |
161 | ||
162 | Date: Thu, 10 Feb 2000 08:46:30 +0100 (MET) | |
163 | From: R.E.Wolff@BitWizard.nl (Rogier Wolff) | |
164 | ||
165 | Lately, while trying to recover a broken disk, my system froze (twice, | |
166 | until I tried something else) while copying the disk. | |
167 | ||
168 | So I had a file of about 50Mb that was growing frantically at the | |
169 | moment of the crash. | |
170 | ||
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: | |
174 | ||
175 | too many invalid blocks. Clear inode? | |
176 | ||
177 | and then I get the option to delete the whole file. Not to truncate | |
178 | the file to a "working" size. | |
179 | ||
180 | ||
181 | I'd MUCH rather have e2fsck say something like: | |
182 | ||
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? | |
186 | ||
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. | |
190 | ||
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 | |
194 | TODO list. | |
195 | ||
196 | - Ted | |
197 | ||
198 | ---------------------------------------------------------------- |