Theodore Ts'o | c4c30b2 | 2003-12-07 02:16:43 -0500 | [diff] [blame] | 1 | Need to process the bad block inode *before* doing the inod scan. |
| 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 | --------------------------------------------------- |
Theodore Ts'o | c461e16 | 1999-01-12 23:40:01 +0000 | [diff] [blame] | 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 |
Theodore Ts'o | e2e69ba | 1999-06-18 01:13:31 +0000 | [diff] [blame] | 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 | |
Theodore Ts'o | e2e69ba | 1999-06-18 01:13:31 +0000 | [diff] [blame] | 27 | --------------------------------- |
Theodore Ts'o | e2e69ba | 1999-06-18 01:13:31 +0000 | [diff] [blame] | 28 | Date: Mon, 08 Mar 1999 21:46:14 +0100 |
| 29 | From: Sergio Polini <s.polini@mclink.it> |
| 30 | |
| 31 | |
| 32 | I'm reading the sorce code of e2fsck 1.14. |
| 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 | |
Theodore Ts'o | e2a99be | 1999-07-19 15:48:08 +0000 | [diff] [blame] | 47 | Add chmod command to debugfs. |
Theodore Ts'o | e2e69ba | 1999-06-18 01:13:31 +0000 | [diff] [blame] | 48 | |
Theodore Ts'o | 8a31ffe | 1999-10-23 03:33:15 +0000 | [diff] [blame] | 49 | ------------------------------------------ |
| 50 | |
Theodore Ts'o | 24ded09 | 1999-11-10 15:56:16 +0000 | [diff] [blame] | 51 | Maybe a bug in debugfs v.1.14: |
| 52 | if a file has more than one hardlink, only the first filename is shown when |
| 53 | using command |
| 54 | ncheck <inode> |
| 55 | |
| 56 | ------------------------------------ |
Theodore Ts'o | fdbba5c | 2000-02-08 23:16:51 +0000 | [diff] [blame] | 57 | |
| 58 | Add a filesystem creation date to the superblock |
| 59 | |
| 60 | ----------------------------------- |
| 61 | Date: Tue, 18 Jan 2000 17:54:53 -0800 (PST) |
| 62 | From: Alan Blanchard <alan@abraxas.to> |
| 63 | To: tytso@MIT.EDU |
| 64 | Subject: DEBUGFS - thanks and a feature idea |
| 65 | Content-Type: TEXT/PLAIN; charset=US-ASCII |
| 66 | |
| 67 | Theodore: |
| 68 | |
| 69 | First, 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 |
| 71 | an "rm -Rf" on a 34 GB drive with about 5GB of data on it. I was able to |
| 72 | restore essentially the entire thing with debugfs and a bit of C code and Perl. |
| 73 | Actually, I could have done the entire thing with debugfs and Perl, but I |
| 74 | thought it would be too slow. |
| 75 | |
| 76 | During this exercise, I noticed that one small feature was lacking that would |
| 77 | have made my job a bit easier. The length of a deleted directory is |
| 78 | reported as 0, hence debugfs won't dump the contents of the directory to a |
| 79 | file using the "dump" command. The only thing that saved me was that the |
| 80 | list of disk blocks is not zeroed out. I was able to dump the contents of the |
| 81 | directories by using debugfs to get the relevant block numbers, then |
| 82 | using dd to get the actual data. |
| 83 | |
| 84 | If debugfs had a feature where it ignored the size of a directory reported by |
| 85 | the inode and instead just dumped all the blocks, it would have facilited |
| 86 | things a bit. This seems like a very easy feature to add. |
| 87 | |
| 88 | Again, thanks for writing debugfs (and all the other Linux stuff you've written!). |
| 89 | |
| 90 | Cheers, |
| 91 | Alan Blanchard |
| 92 | alan@abraxas.to |
| 93 | |
| 94 | |
| 95 | ------------------------------------------------------------------- |
| 96 | |
| 97 | Date: Fri, 21 Jan 2000 14:07:12 -0800 |
| 98 | From: "H. Peter Anvin" <hpa@www.transmeta.com> |
| 99 | Subject: mkfs -cc and fsck -c |
| 100 | |
Theodore Ts'o | fdbba5c | 2000-02-08 23:16:51 +0000 | [diff] [blame] | 101 | b) An option to mkfs to zero the partition. Yes, it can be done with |
| 102 | dd, but it would be a nicer way of doing it. |
| 103 | |
Theodore Ts'o | 1917875 | 2000-02-11 15:55:07 +0000 | [diff] [blame] | 104 | ------------------------------------------------------------------ |
| 105 | |
| 106 | Add support for in ext2fs_block_iterate() for a returning the |
| 107 | compressed flag blocks to block_iterate. Change default to not return |
| 108 | EXT2_COMPRESSED_BLKADDR. Change e2fsck to pass this flag in. |
| 109 | |
| 110 | (The old compression patches did this by default all the time, which |
| 111 | is bad, since it meant e2fsck never saw the EXT2_COMPRESSED_BLKADDR |
| 112 | flagword. |
| 113 | |
| 114 | ------------------------------------------------------------ |
| 115 | |
| 116 | E2fsck should offer to clear all the blocks in an indirect block, not |
| 117 | the entire inode, so there's better recovery for when an indirect |
| 118 | block gets trashed. |
| 119 | |
| 120 | |
Theodore Ts'o | cc73e04 | 2000-04-06 23:05:32 +0000 | [diff] [blame] | 121 | ------------------------------------------------------------- |
| 122 | |
| 123 | From: Yann Dirson - LOGATIQUE <Yann.Dirson@France.Sun.COM> |
| 124 | Date: Thu, 2 Mar 2000 13:52:13 +0100 (MET) |
| 125 | |
| 126 | During my experiments on the broken system, I noticed the following in |
| 127 | the 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 |
| 131 | probably read something like end_count. |
| 132 | |
| 133 | * testing past end of device is not detected, and lists those blocks |
| 134 | as bad, whereas they simply do not exist. |
| 135 | |
| 136 | |
| 137 | I think I'll probably add a "max count" option to findsuper(8), so |
| 138 | that I do not have to wait for the whole disk to be scanned when the |
| 139 | system had to be launched with "init=/bin/sh", in which case Ctrl-[CZ] |
| 140 | and friends appear to be absolutely ignored. |
| 141 | |
| 142 | |
| 143 | Somewhat unrelated, I just noticed the |
| 144 | http://web.mit.edu/tytso/www/linux/ext2.html could be updated: |
| 145 | |
Theodore Ts'o | cc73e04 | 2000-04-06 23:05:32 +0000 | [diff] [blame] | 146 | - could mention SGI xfs (http://oss.sgi.com/projects/xfs/ - they just |
| 147 | release 0.03 snapshot) |
| 148 | |
| 149 | ---------------------------------------------------------------- |
| 150 | |
| 151 | Return-Path: <tytso@MIT.EDU> |
| 152 | Date: Thu, 10 Feb 2000 13:20:14 -0500 |
| 153 | From: "Theodore Y. Ts'o" <tytso@MIT.EDU> |
| 154 | To: R.E.Wolff@BitWizard.nl |
| 155 | In-Reply-To: Rogier Wolff's message of Thu, 10 Feb 2000 08:46:30 +0100 (MET), |
| 156 | <200002100746.IAA24573@cave.bitwizard.nl> |
| 157 | Subject: Re: e2fsck request for enhancement. |
| 158 | Phone: (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 | |
| 189 | That's a good point. Actually, the right thing is for e2fsck to offer |
| 190 | to clear all of the bad blocks in a particular indirect block. I don't |
| 191 | know how hard it would be to do that, but I'll put it on my e2fsprogs |
| 192 | TODO list. |
| 193 | |
| 194 | - Ted |
| 195 | |
Theodore Ts'o | d3cd93c | 2000-10-24 18:33:16 +0000 | [diff] [blame] | 196 | ----------------------------------------------------------------- |
Theodore Ts'o | 0cf43d8 | 2001-05-11 05:12:07 +0000 | [diff] [blame] | 197 | |
| 198 | Debugfs's link command should set the file type information |
| 199 | |
| 200 | --------------------------------------------------------------- |
Theodore Ts'o | 151c86a | 2003-07-25 07:03:00 -0400 | [diff] [blame] | 201 | From e2fsprogs Debian TODO file as of 1.10-13. |
| 202 | |
| 203 | * Maybe make -dbg packages. Look at how others do it. |
| 204 | |
Theodore Ts'o | 6d037b3 | 2004-03-02 11:18:21 -0500 | [diff] [blame^] | 205 | --------------------------------------------------------------- |
| 206 | |
| 207 | Add --lba option to debian icheck command, and have ways of making it |
| 208 | easier to translate LBA to filesystem block numbers. |