First 128KB of XFS partition is NULL.

First 128KB of XFS partition is NULL.

[Ajeet Yadav]

Dear All,
I have received a corrupted disk from team testing XFS, when I look
hexdump of partiton. Its 0000 in first 128KB.
Our kernel is 2.6.30.9 however we have backported XFS from 2.6.34,
Arch MIP with VIPT cache.
This arch previously had many issues but after properly implementing
"xfs: fix xfs to work with Virtually Indexed architectures " most
problem resolved.

Can anyone make guess in what case first 128KB may become NULL, I seem
to be impossible because file system does not modify all 128KB at the
begining of partition at once.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: First 128KB of XFS partition is NULL.

[Ajeet Yadav]

Testing team provides a very little information, but after checking
all possiblity I cam to conclusion that he may have removed the USB
during formating when mkfs.xfs just finished "Zero out the beginning
of the device, to obliterate any old filesystem signatures out there"

Issue resolved, thanks

On Sun, Feb 20, 2011 at 11:22 AM, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
> Dear All,
> I have received a corrupted disk from team testing XFS, when I look
> hexdump of partiton. Its 0000 in first 128KB.
> Our kernel is 2.6.30.9 however we have backported XFS from 2.6.34,
> Arch MIP with VIPT cache.
> This arch previously had many issues but after properly implementing
> "xfs: fix xfs to work with Virtually Indexed architectures " most
> problem resolved.
>
> Can anyone make guess in what case first 128KB may become NULL, I seem
> to be impossible because file system does not modify all 128KB at the
> begining of partition at once.
>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: First 128KB of XFS partition is NULL.

[Eric Sandeen]

On 2/19/11 8:45 PM, Ajeet Yadav wrote:
> Testing team provides a very little information, but after checking
> all possiblity I cam to conclusion that he may have removed the USB
> during formating when mkfs.xfs just finished "Zero out the beginning
> of the device, to obliterate any old filesystem signatures out there"

That sounds plausible...

Just for reference, there are runtime checks to be sure we don't overwrite
block zero due to bad mappings; see "Access to block zero" message in
xfs_cmn_err_fsblock_zero() and xfs_bmap_search_extents()

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: First 128KB of XFS partition is NULL.

[Dave Chinner]

On Sun, Feb 20, 2011 at 11:22:34AM +0900, Ajeet Yadav wrote:
> Dear All,
> I have received a corrupted disk from team testing XFS, when I look
> hexdump of partiton. Its 0000 in first 128KB.
> Our kernel is 2.6.30.9 however we have backported XFS from 2.6.34,
> Arch MIP with VIPT cache.
> This arch previously had many issues but after properly implementing
> "xfs: fix xfs to work with Virtually Indexed architectures " most
> problem resolved.
> 
> Can anyone make guess in what case first 128KB may become NULL, I seem
> to be impossible because file system does not modify all 128KB at the
> begining of partition at once.

Something else wrote to the block device. Maybe a partitioning
program, a boot loader or possibly something else entirely...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs