Re: cgd on dk on 4k block size disk

[Thomas Klausner <tk%giga.or.at@localhost>]

On Thu, Jun 06, 2013 at 07:37:18AM +0200, Michael van Elst wrote:
> On Wed, Jun 05, 2013 at 11:10:58PM +0200, Thomas Klausner wrote:
> > I've restarted from scratch (gpt destroy) and created the file system
> > with "newfs ... -S 4096 ..." which gave me a working file system which
> > survived a forced fsck.
> 
> What sector size did newfs see when you didn't use -S 4096 ?

Sorry, I didn't try that.

> Did you just add -S 4096 and everything seemed to work? Or did you
> also specify the filesystem size with -s ?

Here's the newfs output:
# newfs -O 2 -b 32k -f 4k -i 128k -m 1 -S 4096 /dev/rdk10
newfs: Warning: changing optimization to space because minfree is less than 5%
/dev/rdk10: 2861587.0MB (732566272 sectors) block size 32768, fragment size 4096
        using 3250 cylinder groups of 880.50MB, 28176 blks, 7040 inodes.
super-block backups (for fsck_ffs -b #) at:
24, 225432, 450840, 676248, 901656, 1127064, 1352472, 1577880, 1803288, 
2028696, 2254104, 2479512, 2704920, 2930328, 3155736, 3381144, 3606552, 
3831960, 4057368, 4282776, 4508
184, 4733592, 4959000, 5184408,
...............................................................................................................................................................................
....................................


> newfs gets the information for the disk in terms of
> - sector size
> - number of sectors
> 
> For an image file (-F option) or when stat() returns a size
> for your block/char device (which ours regularly do not do)
> the number of sectors is computed from that size.
> 
> Otherwise, the number of sectors is taken from the geometry
> or disklabel.
> 
> -S overrides only the sector size
> -s overrides only the number of sectors
> 
> So, just specifying -S for a disk device keeps the number of sectors
> but changes the sector size and thus the size of the disk.
> 
> Please check the output of newfs, it will tell you the assumed size
> of the disk in bytes and in sectors.

The output looks approximately right. At least not a factor of 8 off.

> Were the high numbers in the range of 8 times the expected block
> number or something really huge?

Ah, I should have written them down. I think they could be in the *8 range.

> If something really huge, it could be random content (like some old cgd
> data) in a place of a metadata block that wasn't written out before
> the crash.
> 
> If something only somewhat to large, it could also be badly computed
> block numbers because of a wrong geometry used when creating the
> filesystem :)

newfs output above, so perhaps that helps :)
 Thomas