Ext3 users - May 2014 - location of file-system information on ext4

Hi,

I zero-filled first 10MiB of my SSD(dd if=/dev/zero of=/dev/sda bs=10M
count=1). As expected, this wiped my primary GPD header and first
partition. Before the wipe, GPT was following:

Disk /dev/sda: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 2EFD285D-F8E6-4262-B380-232E866AF15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 1-sector boundaries
Total free space is 16 sectors (8.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34        58593784   27.9 GiB    EF00  root part
   2        58593785       234375035   83.8 GiB    0700  home part
   3       234375036       250069630   7.5 GiB     8200  swap part


However, to my surprise, the file(1) and dumpe2fs(8) utilities were
still able to show information regarding file system:

root at T60:~# file -s /dev/sda1
/dev/sda1: sticky Linux rev 1.0 ext4 filesystem data,
UUID=88e70e1b-4c45-4e7e-931f-9e97d7257ee8 (needs journal recovery)
(extents) (large files) (huge files)
root at T60:~# dumpe2fs /dev/sda1
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          88e70e1b-4c45-4e7e-931f-9e97d7257ee8
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file
huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1831424
Block count:              7324218
Reserved block count:     366210
Free blocks:              4511822
Free inodes:              1671701
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Wed Jul 10 23:01:50 2013
Last mount time:          Mon May  5 19:28:01 2014
Last write time:          Mon May  5 19:28:01 2014
Mount count:              14
Maximum mount count:      34
Last checked:             Sun Jan 26 15:32:00 2014
Check interval:           15552000 (6 months)
Next check after:         Fri Jul 25 15:32:00 2014
Lifetime writes:          61 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       1439005
Default directory hash:   half_md4
Directory Hash Seed:      f7476ad6-3067-4697-93b3-f4a368d76eab
Journal backup:           inode blocks
Journal superblock magic number invalid!
root at T60:~#


Am I correct that there are multiple super-blocks scattered around the
HDD and if first one is missing, then next one is read by file or
dumpe2fs utilities? In the first place, what (important) file-system
data is written at the beginning of the partition?



regards,
Martin

On Sat, May 10, 2014 at 06:42:50PM +0000, Martin T
wrote:
> 
> Am I correct that there are multiple super-blocks scattered around the
> HDD and if first one is missing, then next one is read by file or
> dumpe2fs utilities? In the first place, what (important) file-system
> data is written at the beginning of the partition?
There are multiple super blocks scattered around the HDD, but they are
used primarily by e2fsck, for the purposes of trying to repair a
corrupted file system.  As far as I know dumpe2fs (definitely) and
file (almost certainly) doesn't fall back and try the alternate
superblocks.

Was the file system mounted at the time when you tried running the dd
command to zero the first 10MB of your SSD?  The only thing I can
think of is that the file system was mounted, and so the superblock
was written back when you zero'ed the SSD, via some artifact of buffer
cache (non-)aliasing.

You could check by running the command od /dev/sda1 | head and seeing
if the first 8k or so of the file system really is all zero's or not.

In answer to your question, portions of the inode table are located at
the begining of the file system, so the root inode would have been
lost if the first 10MB or so of the file system really was smashed.

     	    	       	     	    	 	- Ted