Does this mean that recovering from this sort of whoops would be easier to do if I
selected partition sizes based on cylinders?  I have never had to get down into
the disk geometry as far as you guys have and with luck won't have to but looks
like there is some good stuff to play with here and learn.

Is dumpefs totaly safe to run as a disk jockey newbie?

Bret

Vidiot wrote:

> > But can you (or perhaps Bero) give a better explanation as to how you
> > determined the partition sizes? You might want to remind us what info you
> > had to start with etc.
> >
> > I'd really like to understand this.
>
> OK, between the two of us looking at stuff, this is the jist of what happened:
>
> The dumpe2fs would find the superblocks in the first file system without a
> hitch.  But it wouldn't find them in the 2nd filesystem.  Bero wrote a
> little program that would call up dumpe2fs and hand it a block to look at.
>
> After a few clues and playing with dd and od, I wrote the following shell
> line to look for the superblock magic number:
>
>         dd bs=1k if=/dev/hdb2 | od -x -A x | grep "ef53 000"
>
> It will produce lines like this on a working system:
>
>         000430 c8c0 38bb 0010 0014 ef53 0003 0001 0000
>         800430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>         1000430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>         1800430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>         2000430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>         2800430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>         3000430 0c31 38b8 0000 0014 ef53 0000 0001 0000
>
> The above is from the first file system.  Notice that the main superblock
> is ef53 0003 for the bytes.  The backup blocks are ef53 0000.
>
> But, this is what I was getting for the bad filesystem:
>
>         0c5230 090b 38b9 0002 0014 ef53 0001 0001 0000
>         8c5230 e2e9 38b8 0000 0014 ef53 0000 0001 0000
>         10c5230 e2e9 38b8 0000 0014 ef53 0000 0001 0000
>         18c5230 e2e9 38b8 0000 0014 ef53 0000 0001 0000
>         20c5230 e2e9 38b8 0000 0014 ef53 0000 0001 0000
>         28c5230 e2e9 38b8 0000 0014 ef53 0000 0001 0000
>
> The main superblock is ef53 0001.  But notice the address.  It was too far
> into the partition. i.e., it wasn't on cylinder boundaries.
>
> It was then that Bero thought about the workings of fdisk and put it into
> sector display mode.  Using dumpe2fs, one can determine what the size is of
> the 1st filesystem:
>
>         dumpe2fs -h /dev/hdb1
>         dumpe2fs 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
>         Filesystem volume name:   ftp
>         Last mounted on:          <not available>
>         Filesystem UUID:          2bc0e64e-ab54-11d3-9f89-e246f22a98c5
>         Filesystem magic number:  0xEF53
>         Filesystem revision #:    0 (original)
>         Filesystem features:     (none)
>         Filesystem state:         not clean with errors
>         Errors behavior:          Continue
>         Filesystem OS type:       Linux
>         Inode count:              623104
>         Block count:              9969088
>         Reserved block count:     498454
>         Free blocks:              4893485
>         Free inodes:              622202
>         First block:              1
>         Block size:               1024
>         Fragment size:            1024
>         Blocks per group:         8192
>         Fragments per group:      8192
>         Inodes per group:         512
>         Inode blocks per group:   64
>         Last mount time:          Tue Feb 29 10:16:54 2000
>         Last write time:          Tue Feb 29 10:16:56 2000
>         Mount count:              19
>         Maximum mount count:      20
>         Last checked:             Sat Feb 26 11:24:01 2000
>         Check interval:           15552000 (6 months)
>         Next check after:         Thu Aug 24 12:24:01 2000
>         Reserved blocks uid:      0 (user root)
>         Reserved blocks gid:      0 (group root)
>
> Notice the block count.  Here is the partition table as it looks repaired:
>
>         Disk /dev/hdb: 255 heads, 63 sectors, 2482 cylinders
>         Units = cylinders of 16065 * 512 bytes
>
>            Device Boot    Start       End    Blocks   Id  System
>         /dev/hdb1             1      1242   9969088+  83  Linux
>         /dev/hdb2          1242      2482   9967545   83  Linux
>
> To get those exact block in, you use "u" to change the display mode:
>
>         Disk /dev/hdb: 255 heads, 63 sectors, 2482 cylinders
>         Units = sectors of 1 * 512 bytes
>
>            Device Boot    Start       End    Blocks   Id  System
>         /dev/hdb1            63  19938239   9969088+  83  Linux
>         /dev/hdb2      19938240  39873329   9967545   83  Linux
>
> Now you can create the partitions by entering the sectors for the ending,
> which is block-count*2+63.  The first 63 sectors contain the partition table
> and boot strap.
>
> Then all he had to do was create the 2nd filesystem starting from where the
> first one left off.
>
> Since I had created this a little whiel ago, I forgot that I didn't enter
> cylinders, but a size value.  Fdisk, it seems, doesn't round to the nearest
> cylinder boundary, hence the weird numbers.
>
> Hope this helps a little bit.  I certainly learned a lot from this
> exercise.  While I don't like how I got there, as I am two days behind in
> getting the web site back up, the learning is a plus.
>
> Any other questions, let me know.
>
> MB
>
> --
> To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
> as the Subject.


-- 
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.

Reply via email to