xfs
[Top] [All Lists]

[Bug 389] New: Untarring an archive corrupts XFS file system

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 389] New: Untarring an archive corrupts XFS file system
From: bugzilla-daemon@xxxxxxxxxxx
Date: Thu, 25 Nov 2004 07:47:42 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx
http://oss.sgi.com/bugzilla/show_bug.cgi?id=389

           Summary: Untarring an archive corrupts XFS file system
           Product: Linux XFS
           Version: 1.3.x
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: High
         Component: XFS kernel code
        AssignedTo: xfs-master@xxxxxxxxxxx
        ReportedBy: james-p@xxxxxxxxxxxxxxxxxx


I have a tar archive that when I extract the files, it results in a corrupt
directory inode.

This is repeatable on _every_ XFS file system I've tried (kernels 2.4.20, 2.4.22
with XFS 1.3.X and what ever version comes with 2.4.26)

It also happens on IRIX (6.5.19m) !!

The tar archive contains one directory with about 500 files.

If extract the files, then move the extracted directory to somewhere else on the
file system, I get an xfs_shutdown.

When I do an xfs_repair I get:

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
bad directory leaf magic # 0x9a62 for directory inode 801 block 8388609
        - agno = 1
        - agno = 2
...
Phase 6 - check inode connectivity...
        - traversing filesystem starting at / ... 
unknown magic number 0x9a62 for block 8388609 in directory inode 801
        - traversal finished ... 
...


I think it has something to do with the order and 'nature' (name, size,
whatever) of the files being added to the directory - as shown by the following
tests:

untar all but the last file in the archive
umount
xfs_repair - no problem
mount
untar just the last file in the archive
umount
xfs_repair - unknown magic number 0x9a62 ...

However, if I do:

untar just the last file in the archive
umount
xfs_repair - no problem
mount
untar all but the last file in the archive
umount
xfs_repair - no problem

Or even:

untar all but the last file in the archive
umount
xfs_repair - no problem
mount
create any new file in problem directory
umount
xfs_repair - no problem
untar just the last file in the archive
umount
xfs_repair - no problem 

This tar archive was made from a repaired corrupted directory on another XFS
file system - the corruption was exactly the same.

I thought it strange that the tar archive 'kept' the corruption - very strange
as a tar archive doesn't contain anything XFS specific ... but it's not the tar
archive, it's the file creation nature and order that triggers the bug. I
believe tar creates archives with files in the 'directory' order i.e. the same
order that the files were created.

Unfortunately, the tar archive is 1.1Gb, so it is a bit difficult to make it
available - it also contains production data, so I don't want to make it widely
available - however I will make it available to the XFS developers (how??)

James Pearson



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


<Prev in Thread] Current Thread [Next in Thread>
  • [Bug 389] New: Untarring an archive corrupts XFS file system, bugzilla-daemon <=