mkfs.xfs created filesystem larger than underlying device

[Eric Sandeen]

Michael Moody wrote:
> It still looks wrong:
> 
> [root at filer5 /]# xfs_info /mnt/Volume1/
> meta-data=/dev/Volume1-Rep-Store/Volume1-Replicated isize=256    agcount=32, agsize=146716768 blks
>          =                       sectsz=512   attr=0
> data     =                       bsize=4096   blocks=4694936576, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=1
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=32768, version=1
>          =                       sectsz=512   sunit=0 blks, lazy-count=0
> realtime =none                   extsz=4096   blocks=0, rtextents=0

4694936576*4096 = 19230460215296

> [root at filer5 /]# df
> Filesystem           1K-blocks      Used Available Use% Mounted on
...
> /dev/mapper/Volume1--Rep--Store-Volume1--Replicated
>                      18779615232      1056 18779614176   1% /mnt/Volume1

18779615232*1024 = 19230325997568

> [root at filer5 /]# cat /proc/partitions
> major minor  #blocks  name
> 
...
>  253     5 18779746304 dm-5

18779746304*1024 = 19230460215296

so in bytes,

xfs_info says:		19230460215296
/proc/partitions says:	19230460215296 (same as above)
df says:		19230325997568 (a little smaller, but ok)

So, I don't see a problem here.

<later....>

> I experienced significant corruption. I had only about 3 files on the
> XFS filesystem, which was then exported via nfs. I ran nfs_stress.sh
> against it, and my files ended up corrupt, and the machine locked up.
> Ideas?

No, not really, not on a kernel this old, and without details about what
was corrupt, what xfs_repair said, what dmesg said, what sysrq-t said, etc.

-Eric