September 23, 20169 yr This is the second time in two days that this Intel 600P 512G NVMe drive has encountered a corrupt XFS file system. The first time I just reformatted the drive as I am testing it and had a backup in place. This time I would like to try and repair the file system. I would like to do the following http://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#xfs_repair "These are just examples, replace drive ID with the correct drive symbol, either an md number (md2, md15, etc) or an sd symbol (sdc1, sdj1, etc). xfs_repair -v /dev/md3 -> tests and reports, making changes when necessary" How do I figure out the drive symbol for this drive? Here is part of the error log Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): Metadata CRC error detected at xfs_agfl_read_verify+0xa5/0xad, xfs_agfl block 0x3 Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): Unmount and run xfs_repair Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): First 64 bytes of corrupted metadata buffer: Sep 23 13:41:47 Tower kernel: ffff880fb7bab000: 14 4a 12 8d 7d 46 bf 48 da ab d8 65 eb 78 45 ba .J..}F.H...e.xE. Sep 23 13:41:47 Tower kernel: ffff880fb7bab010: 74 fc 41 48 ff d7 9c 61 32 b9 d3 fd 08 57 be 79 t.AH...a2....W.y Sep 23 13:41:47 Tower kernel: ffff880fb7bab020: 58 9f 29 21 b3 91 bb 93 49 de 27 5c 69 d8 85 f9 X.)!....I.'\i... Sep 23 13:41:47 Tower kernel: ffff880fb7bab030: 9b d6 71 62 4d 3c cf c4 bd c1 7f 0e b4 0d 2d d0 ..qbM<........-. Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): metadata I/O error: block 0x3 ("xfs_trans_read_buf_map") error 74 numblks 1 Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): Internal error xfs_trans_cancel at line 990 of file fs/xfs/xfs_trans.c. Caller xfs_inactive_truncate+0xb9/0xce Sep 23 13:41:47 Tower kernel: CPU: 20 PID: 10922 Comm: python Not tainted 4.4.19-unRAID #1 Sep 23 13:41:47 Tower kernel: Hardware name: Rackable Systems Inc. CYPRESS11/S2600CP, BIOS SE5C600.86B.02.06.0002.101320150901 10/13/2015 Sep 23 13:41:47 Tower kernel: 0000000000000000 ffff880fb9b0fdc8 ffffffff8136a68e ffff880fb7a700e8 Sep 23 13:41:47 Tower kernel: ffffffff8165bfc0 ffff880fb9b0fde0 ffffffff812753dd ffffffff81281216 Sep 23 13:41:47 Tower kernel: ffff880fb9b0fe08 ffffffff812895f3 00000000ffffff8b ffff880fb64a8000 Sep 23 13:41:47 Tower kernel: Call Trace: Sep 23 13:41:47 Tower kernel: [<ffffffff8136a68e>] dump_stack+0x61/0x7e Sep 23 13:41:47 Tower kernel: [<ffffffff812753dd>] xfs_error_report+0x32/0x35 Sep 23 13:41:47 Tower kernel: [<ffffffff81281216>] ? xfs_inactive_truncate+0xb9/0xce Sep 23 13:41:47 Tower kernel: [<ffffffff812895f3>] xfs_trans_cancel+0x49/0xbf Sep 23 13:41:47 Tower kernel: [<ffffffff81281216>] xfs_inactive_truncate+0xb9/0xce Sep 23 13:41:47 Tower kernel: [<ffffffff81281bfc>] xfs_inactive+0xa2/0xc1 Sep 23 13:41:47 Tower kernel: [<ffffffff81285e71>] xfs_fs_evict_inode+0x90/0x93 Sep 23 13:41:47 Tower kernel: [<ffffffff8111df0a>] evict+0xaf/0x164 Sep 23 13:41:47 Tower kernel: [<ffffffff8111ea56>] iput+0x160/0x16d Sep 23 13:41:47 Tower kernel: [<ffffffff81115ddf>] do_unlinkat+0x125/0x201 Sep 23 13:41:47 Tower kernel: [<ffffffff8111642a>] SyS_unlink+0x11/0x13 Sep 23 13:41:47 Tower kernel: [<ffffffff81620a2e>] entry_SYSCALL_64_fastpath+0x12/0x6d Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): xfs_do_force_shutdown(0x8) called from line 991 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8128960c Sep 23 13:41:47 Tower kernel: XFS (nvme0n1p1): Corruption of in-memory data detected. Shutting down filesystem edit: by entering lsblk i get the following (just the relevant part) nvme0n1 259:0 0 477G 0 disk ??nvme0n1p1 259:1 0 477G 0 part entered the following root@Tower:~# xfs_repair -v /dev/nvme0n1 resulting in Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ...................................................... It is now scanning the drive tower-diagnostics-20160923-1419.zip
September 23, 20169 yr Author OK so it is scanning and has come up with the following a number of times ...found candidate secondary superblock... unable to verify superblock, continuing... Question: Is there an inherent problem when using NVMe drives with the XFS file system? Or is this a bad drive?
September 23, 20169 yr Author This is the result of the repair ..Sorry, could not find valid secondary superblock Exiting now. Any advice ... other than just reformatting the drive and not using XFS?
September 23, 20169 yr Community Expert xfs_repair /dev/nvme0n1p1 You need the p1 in the end to specify the partition.
September 23, 20169 yr Author OK missed that running it with the correct description, I get the following root@Tower:~# xfs_repair -v /dev/nvme0n1p1 Phase 1 - find and verify superblock... - block cache size set to 12360648 entries Phase 2 - using internal log - zero log... zero_log: head block 434369 tail block 433400 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Ran it again with the -L option and that seems to have worked. Is there anything that I can do to stop this happening? Should I switch file systems on this drive?
September 23, 20169 yr Community Expert XFS is considered stable, more than BTRFS, make sure you have a UPS to avoid power cuts.
Archived
This topic is now archived and is closed to further replies.