* How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes @ 2012-01-21 10:29 Christian Kildau 2012-01-23 4:31 ` Dave Chinner 0 siblings, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-21 10:29 UTC (permalink / raw) To: xfs Sorry if this message appears twice! Hello, I'm having some very serious issues with XFS after upgrading from a Linux Distro running Ubuntu 2.6.32 to 3.2. It seems like my filesystems are damaged after attaching them to a Linux 3.2 server. I am also no longer able to mount the hdd on the old server that is still running 2.6.32! (I created the xfs filesystem on the entire hdd, not on a partition, so /dev/sdd is not a typo) $ sudo mount -t xfs /dev/sdd /media/ mount: /dev/sdd: can't read superblock (dmesg) [236659.912663] attempt to access beyond end of device [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 [236659.912670] XFS (sdd): last sector read failed $ sudo xfs_check /dev/sdd xfs_check: error - read only 0 of 512 bytes $ sudo xfs_repair /dev/sdd Phase 1 - find and verify superblock... xfs_repair: error - read only 0 of 512 bytes 'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd. Is there any way I can fix this? - Except restroring from backup? Because this IS my backup! see ubuntuforums.org/showthread.php?t=1910962 for more details… Any help is appreciated! Thanks in advance Chris _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-21 10:29 How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes Christian Kildau @ 2012-01-23 4:31 ` Dave Chinner 2012-01-23 9:23 ` Christian Kildau 2012-01-23 10:43 ` Christian Kildau 0 siblings, 2 replies; 21+ messages in thread From: Dave Chinner @ 2012-01-23 4:31 UTC (permalink / raw) To: Christian Kildau; +Cc: xfs On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: > Sorry if this message appears twice! > > > > Hello, > > I'm having some very serious issues with XFS after upgrading from a > Linux Distro running Ubuntu 2.6.32 to 3.2. > > It seems like my filesystems are damaged after attaching them to a > Linux 3.2 server. I am also no longer able to mount the hdd on the old > server that is still running 2.6.32! I take it that you are using external storage of some kind? Can you describe it? > (I created the xfs filesystem on the entire hdd, not on a partition, > so /dev/sdd is not a typo) > > $ sudo mount -t xfs /dev/sdd /media/ > mount: /dev/sdd: can't read superblock > (dmesg) > [236659.912663] attempt to access beyond end of device > [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 > [236659.912670] XFS (sdd): last sector read failed So XFS has asked to read 2113 sectors beyond the size of the device that the kernel is reporting. What is the output of /proc/partitions? > $ sudo xfs_check /dev/sdd > xfs_check: error - read only 0 of 512 bytes > > $ sudo xfs_repair /dev/sdd > Phase 1 - find and verify superblock... > xfs_repair: error - read only 0 of 512 bytes So both buffered and direct IO to the first block in the block device are failing. I'd say your problems have nothing to do with XFS. However, can you strace them and find out what the error that is occuring actually is? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-23 4:31 ` Dave Chinner @ 2012-01-23 9:23 ` Christian Kildau 2012-01-24 5:04 ` Eric Sandeen 2012-01-23 10:43 ` Christian Kildau 1 sibling, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-23 9:23 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs [-- Attachment #1: Type: text/plain, Size: 2285 bytes --] On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote: > On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: >> Sorry if this message appears twice! >> >> >> >> Hello, >> >> I'm having some very serious issues with XFS after upgrading from a >> Linux Distro running Ubuntu 2.6.32 to 3.2. >> >> It seems like my filesystems are damaged after attaching them to a >> Linux 3.2 server. I am also no longer able to mount the hdd on the old >> server that is still running 2.6.32! > > I take it that you are using external storage of some kind? Can you > describe it? This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata. Also it doesn't make any difference if I connect it back to the 'old' server > >> (I created the xfs filesystem on the entire hdd, not on a partition, >> so /dev/sdd is not a typo) >> >> $ sudo mount -t xfs /dev/sdd /media/ >> mount: /dev/sdd: can't read superblock >> (dmesg) >> [236659.912663] attempt to access beyond end of device >> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 >> [236659.912670] XFS (sdd): last sector read failed > > So XFS has asked to read 2113 sectors beyond the size of the device > that the kernel is reporting. What is the output of > /proc/partitions? $ grep sdd /proc/partitions 8 64 1465137527 sdd > >> $ sudo xfs_check /dev/sdd >> xfs_check: error - read only 0 of 512 bytes >> >> $ sudo xfs_repair /dev/sdd >> Phase 1 - find and verify superblock... >> xfs_repair: error - read only 0 of 512 bytes > > So both buffered and direct IO to the first block in the block > device are failing. I'd say your problems have nothing to do with > XFS. However, can you strace them and find out what the error that > is occuring actually is? Strace is giving me: wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000) xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. xfs_check: read failed: Invalid argument cache_node_purge: refcount was 1, not zero (node=0x21ecef0) xfs_check: cannot read root inode (22) bad superblock magic number 0, giving up I attached the entire strace logs to this email. [-- Attachment #2: xfs_check.strace --] [-- Type: application/octet-stream, Size: 3712 bytes --] execve("/usr/sbin/xfs_check", ["xfs_check", "/dev/sdd"], [/* 21 vars */]) = 0 brk(0) = 0x734000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a4a05000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0 mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f19a49ff000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0 mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f19a4445000 mprotect(0x7f19a45dc000, 2097152, PROT_NONE) = 0 mmap(0x7f19a47dc000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f19a47dc000 mmap(0x7f19a47e1000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f19a47e1000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a49fe000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f19a49fc000 arch_prctl(ARCH_SET_FS, 0x7f19a49fc720) = 0 mprotect(0x7f19a47dc000, 16384, PROT_READ) = 0 mprotect(0x619000, 4096, PROT_READ) = 0 mprotect(0x7f19a4a07000, 4096, PROT_READ) = 0 munmap(0x7f19a49ff000, 23783) = 0 getpid() = 28928 rt_sigaction(SIGCHLD, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0 geteuid() = 0 brk(0) = 0x734000 brk(0x755000) = 0x755000 getppid() = 28927 stat("/root", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat(".", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 open("/usr/sbin/xfs_check", O_RDONLY) = 3 fcntl(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f19a447b430}, NULL, 8) = 0 read(10, "#!/bin/sh -f\n#\n# Copyright (c) 2"..., 8192) = 698 stat("/usr/local/sbin/xfs_db", 0x7fffa2d5d780) = -1 ENOENT (No such file or directory) stat("/usr/local/bin/xfs_db", 0x7fffa2d5d780) = -1 ENOENT (No such file or directory) stat("/usr/sbin/xfs_db", {st_mode=S_IFREG|0755, st_size=438344, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f19a49fc9f0) = 28929 wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000) xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. xfs_check: read failed: Invalid argument cache_node_purge: refcount was 1, not zero (node=0x21ecef0) xfs_check: cannot read root inode (22) bad superblock magic number 0, giving up [{WIFEXITED(s) && WEXITSTATUS(s) == 3}], 0, NULL) = 28929 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigreturn(0x11) = 28929 exit_group(3) = ? [-- Attachment #3: xfs_repair.strace --] [-- Type: application/octet-stream, Size: 7958 bytes --] execve("/sbin/xfs_repair", ["xfs_repair", "/dev/sde"], [/* 21 vars */]) = 0 brk(0) = 0xcf5000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82c5000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0 mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dc82bf000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=18896, ...}) = 0 mmap(NULL, 2113944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7ea2000 mprotect(0x7f4dc7ea6000, 2093056, PROT_NONE) = 0 mmap(0x7f4dc80a5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f4dc80a5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200!\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=31752, ...}) = 0 mmap(NULL, 2128984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7c9a000 mprotect(0x7f4dc7ca1000, 2093056, PROT_NONE) = 0 mmap(0x7f4dc7ea0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f4dc7ea0000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240k\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=135217, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82be000 mmap(NULL, 2212888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc7a7d000 mprotect(0x7f4dc7a95000, 2093056, PROT_NONE) = 0 mmap(0x7f4dc7c94000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f4dc7c94000 mmap(0x7f4dc7c96000, 13336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7c96000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0 mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4dc76db000 mprotect(0x7f4dc7872000, 2097152, PROT_NONE) = 0 mmap(0x7f4dc7a72000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f4dc7a72000 mmap(0x7f4dc7a77000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7a77000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82bd000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc82bb000 arch_prctl(ARCH_SET_FS, 0x7f4dc82bb760) = 0 mprotect(0x7f4dc7a72000, 16384, PROT_READ) = 0 mprotect(0x7f4dc7c94000, 4096, PROT_READ) = 0 mprotect(0x7f4dc7ea0000, 4096, PROT_READ) = 0 mprotect(0x7f4dc80a5000, 4096, PROT_READ) = 0 mprotect(0x671000, 4096, PROT_READ) = 0 mprotect(0x7f4dc82c7000, 4096, PROT_READ) = 0 munmap(0x7f4dc82bf000, 23783) = 0 set_tid_address(0x7f4dc82bba30) = 28633 set_robust_list(0x7f4dc82bba40, 0x18) = 0 futex(0x7fffb24a3f1c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7f4dc82bb760) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7f4dc7a83680, [], SA_RESTORER|SA_SIGINFO, 0x7f4dc7a8cc10}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f4dc7a83710, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f4dc7a8cc10}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0xcf5000 brk(0xd16000) = 0xd16000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0 mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f4dc7412000 close(3) = 0 getcwd("/root", 4096) = 6 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ustat(0x840, 0x7fffb24a2950) = -1 EINVAL (Invalid argument) open("/dev/sde", O_RDONLY) = 3 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ustat(0x840, 0x7fffb24a2950) = -1 EINVAL (Invalid argument) open("/dev/sde", O_RDWR|O_EXCL|O_DIRECT) = 4 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ioctl(4, BLKGETSIZE64, 0x7fffb24a2ac0) = 0 ioctl(4, BLKSSZGET, 0x6732e0) = 0 chdir("/root") = 0 brk(0xd37000) = 0xd37000 close(3) = 0 getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 time(NULL) = 1327310356 time(NULL) = 1327310356 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7411000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2570 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7f4dc7411000, 4096) = 0 open("/usr/share/locale/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Phase 1 - find and verify superb"..., 40Phase 1 - find and verify superblock... ) = 40 mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7391000 mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4dc7310000 lseek(4, 0, SEEK_SET) = 0 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524288) = 524288 munmap(0x7f4dc7310000, 528384) = 0 brk(0xd6d000) = 0xd6d000 lseek(4, 375075479552, SEEK_SET) = 375075479552 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 lseek(4, 750150959104, SEEK_SET) = 750150959104 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 lseek(4, 1125226438656, SEEK_SET) = 1125226438656 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 munmap(0x7f4dc7391000, 528384) = 0 time(NULL) = 1327310357 pread(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 0) = 32768 pread(4, "", 512, 1500301909504) = 0 write(2, "xfs_repair: error - read only 0 "..., 45xfs_repair: error - read only 0 of 512 bytes ) = 45 exit_group(1) = ? [-- Attachment #4: Type: text/plain, Size: 87 bytes --] Do you have any idea what has caused this or how to fix it? Thanks in advance! Chris [-- Attachment #5: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-23 9:23 ` Christian Kildau @ 2012-01-24 5:04 ` Eric Sandeen 2012-01-24 7:08 ` Christian Kildau 2012-01-24 10:13 ` Christian Kildau 0 siblings, 2 replies; 21+ messages in thread From: Eric Sandeen @ 2012-01-24 5:04 UTC (permalink / raw) To: Christian Kildau; +Cc: xfs On 1/23/12 3:23 AM, Christian Kildau wrote: > On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote: > >> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: >>> Sorry if this message appears twice! >>> Argh. ;) >>> >>> Hello, >>> >>> I'm having some very serious issues with XFS after upgrading from a >>> Linux Distro running Ubuntu 2.6.32 to 3.2. >>> >>> It seems like my filesystems are damaged after attaching them to a >>> Linux 3.2 server. I am also no longer able to mount the hdd on the old >>> server that is still running 2.6.32! >> >> I take it that you are using external storage of some kind? Can you >> describe it? > > This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata. > Also it doesn't make any difference if I connect it back to the 'old' server > >> >>> (I created the xfs filesystem on the entire hdd, not on a partition, >>> so /dev/sdd is not a typo) I wonder if your installer helpfully scribbled something on it since it had no partitions (which should be safe, but there are dumb apps out there). >>> $ sudo mount -t xfs /dev/sdd /media/ >>> mount: /dev/sdd: can't read superblock >>> (dmesg) >>> [236659.912663] attempt to access beyond end of device >>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 >>> [236659.912670] XFS (sdd): last sector read failed >> >> So XFS has asked to read 2113 sectors beyond the size of the device >> that the kernel is reporting. What is the output of >> /proc/partitions? > > $ grep sdd /proc/partitions > 8 64 1465137527 sdd so 1465137527*1024 = 1500300827648 bytes >From the strace repair is trying to read at: pread(4, "", 512, 1500301909504) = 0 which is about 1 meg past the end of the device. >> >>> $ sudo xfs_check /dev/sdd >>> xfs_check: error - read only 0 of 512 bytes >>> >>> $ sudo xfs_repair /dev/sdd >>> Phase 1 - find and verify superblock... >>> xfs_repair: error - read only 0 of 512 bytes >> >> So both buffered and direct IO to the first block in the block >> device are failing. I'd say your problems have nothing to do with >> XFS. However, can you strace them and find out what the error that >> is occuring actually is? > > Strace is giving me: > wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000) now that is something else... > xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. > xfs_check: read failed: Invalid argument > cache_node_purge: refcount was 1, not zero (node=0x21ecef0) > xfs_check: cannot read root inode (22) > bad superblock magic number 0, giving up those are different failures than first reported.... xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting. -Eric > I attached the entire strace logs to this email. > > > > > > Do you have any idea what has caused this or how to fix it? > > Thanks in advance! > Chris > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 5:04 ` Eric Sandeen @ 2012-01-24 7:08 ` Christian Kildau 2012-01-24 10:13 ` Christian Kildau 1 sibling, 0 replies; 21+ messages in thread From: Christian Kildau @ 2012-01-24 7:08 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs On Jan 24, 2012, at 6:04 AM, Eric Sandeen wrote: > On 1/23/12 3:23 AM, Christian Kildau wrote: >> On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote: >> >>> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: >>>> Sorry if this message appears twice! >>>> > > Argh. ;) > >>>> >>>> Hello, >>>> >>>> I'm having some very serious issues with XFS after upgrading from a >>>> Linux Distro running Ubuntu 2.6.32 to 3.2. >>>> >>>> It seems like my filesystems are damaged after attaching them to a >>>> Linux 3.2 server. I am also no longer able to mount the hdd on the old >>>> server that is still running 2.6.32! >>> >>> I take it that you are using external storage of some kind? Can you >>> describe it? >> >> This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata. >> Also it doesn't make any difference if I connect it back to the 'old' server >> >>> >>>> (I created the xfs filesystem on the entire hdd, not on a partition, >>>> so /dev/sdd is not a typo) > > I wonder if your installer helpfully scribbled something on it since it > had no partitions (which should be safe, but there are dumb apps out there). This is a new system. I connected the hdd waaay after the installation. So the installer has never seen it. ;) > >>>> $ sudo mount -t xfs /dev/sdd /media/ >>>> mount: /dev/sdd: can't read superblock >>>> (dmesg) >>>> [236659.912663] attempt to access beyond end of device >>>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 >>>> [236659.912670] XFS (sdd): last sector read failed >>> >>> So XFS has asked to read 2113 sectors beyond the size of the device >>> that the kernel is reporting. What is the output of >>> /proc/partitions? >> >> $ grep sdd /proc/partitions >> 8 64 1465137527 sdd > > so 1465137527*1024 = 1500300827648 bytes > > From the strace repair is trying to read at: > > pread(4, "", 512, 1500301909504) = 0 > > which is about 1 meg past the end of the device. That's weird! Any chance left I can fix this? > >>> >>>> $ sudo xfs_check /dev/sdd >>>> xfs_check: error - read only 0 of 512 bytes >>>> >>>> $ sudo xfs_repair /dev/sdd >>>> Phase 1 - find and verify superblock... >>>> xfs_repair: error - read only 0 of 512 bytes >>> >>> So both buffered and direct IO to the first block in the block >>> device are failing. I'd say your problems have nothing to do with >>> XFS. However, can you strace them and find out what the error that >>> is occuring actually is? >> >> Strace is giving me: >> wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000) > > now that is something else… Yes, sorry. that was my fault. Wrong hdd. see my other message for the correct straces. > >> xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. >> xfs_check: read failed: Invalid argument >> cache_node_purge: refcount was 1, not zero (node=0x21ecef0) >> xfs_check: cannot read root inode (22) >> bad superblock magic number 0, giving up > > those are different failures than first reported.... > > xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting. > xfs_db: error - read only 0 of 512 bytes magicnum = 0x58465342 blocksize = 4096 dblocks = 366284646 rblocks = 0 rextents = 0 uuid = 65b7d940-6577-4384-b7ba-f051300f2d56 logstart = 268435460 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 1 agblocks = 91571162 agcount = 4 rbmblocks = 0 logblocks = 32768 versionnum = 0xb4a4 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 27 rextslog = 0 inprogress = 0 imax_pct = 5 icount = 5184 ifree = 16 fdblocks = 54646459 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 1 features2 = 0x8 bad_features2 = 0x8 I don't get anything useful from that information ;) Thanks in advance! Chris _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 5:04 ` Eric Sandeen 2012-01-24 7:08 ` Christian Kildau @ 2012-01-24 10:13 ` Christian Kildau 2012-01-24 14:12 ` Roger Willcocks 1 sibling, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-24 10:13 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs Top posting... sorry. I have now found dozens of other users with a similar issue! e.g. http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). On Jan 24, 2012, at 6:04 AM, Eric Sandeen wrote: > On 1/23/12 3:23 AM, Christian Kildau wrote: >> On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote: >> >>> On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: >>>> Sorry if this message appears twice! >>>> > > Argh. ;) > >>>> >>>> Hello, >>>> >>>> I'm having some very serious issues with XFS after upgrading from a >>>> Linux Distro running Ubuntu 2.6.32 to 3.2. >>>> >>>> It seems like my filesystems are damaged after attaching them to a >>>> Linux 3.2 server. I am also no longer able to mount the hdd on the old >>>> server that is still running 2.6.32! >>> >>> I take it that you are using external storage of some kind? Can you >>> describe it? >> >> This hdd is connected via e-sata, but it doesn't make any difference if I directly connect it internally via sata. >> Also it doesn't make any difference if I connect it back to the 'old' server >> >>> >>>> (I created the xfs filesystem on the entire hdd, not on a partition, >>>> so /dev/sdd is not a typo) > > I wonder if your installer helpfully scribbled something on it since it > had no partitions (which should be safe, but there are dumb apps out there). > >>>> $ sudo mount -t xfs /dev/sdd /media/ >>>> mount: /dev/sdd: can't read superblock >>>> (dmesg) >>>> [236659.912663] attempt to access beyond end of device >>>> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 >>>> [236659.912670] XFS (sdd): last sector read failed >>> >>> So XFS has asked to read 2113 sectors beyond the size of the device >>> that the kernel is reporting. What is the output of >>> /proc/partitions? >> >> $ grep sdd /proc/partitions >> 8 64 1465137527 sdd > > so 1465137527*1024 = 1500300827648 bytes > > From the strace repair is trying to read at: > > pread(4, "", 512, 1500301909504) = 0 > > which is about 1 meg past the end of the device. > >>> >>>> $ sudo xfs_check /dev/sdd >>>> xfs_check: error - read only 0 of 512 bytes >>>> >>>> $ sudo xfs_repair /dev/sdd >>>> Phase 1 - find and verify superblock... >>>> xfs_repair: error - read only 0 of 512 bytes >>> >>> So both buffered and direct IO to the first block in the block >>> device are failing. I'd say your problems have nothing to do with >>> XFS. However, can you strace them and find out what the error that >>> is occuring actually is? >> >> Strace is giving me: >> wait4(-1, xfs_check: /dev/sdd is not a valid XFS filesystem (unexpected SB magic number 0x00000000) > > now that is something else... > >> xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided. >> xfs_check: read failed: Invalid argument >> cache_node_purge: refcount was 1, not zero (node=0x21ecef0) >> xfs_check: cannot read root inode (22) >> bad superblock magic number 0, giving up > > those are different failures than first reported.... > > xfs_db -c "sb 0" -c "p" /dev/sdd still might be interesting. > > -Eric > >> I attached the entire strace logs to this email. >> >> >> >> >> >> Do you have any idea what has caused this or how to fix it? >> >> Thanks in advance! >> Chris >> >> >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 10:13 ` Christian Kildau @ 2012-01-24 14:12 ` Roger Willcocks 2012-01-24 15:46 ` Christian Kildau 0 siblings, 1 reply; 21+ messages in thread From: Roger Willcocks @ 2012-01-24 14:12 UTC (permalink / raw) To: Christian Kildau; +Cc: Eric Sandeen, xfs On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote: > Top posting... sorry. > > I have now found dozens of other users with a similar issue! e.g. > http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ > > To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). > It seems fairly clear that your drive or the bios is lying about its capacity. The filesystem occupies the entire disk, but the disk has become 'smaller'. A quick web search suggests a 'hidden protected area' - the two block counts in this link line up with the before and after sizes you're seeing: http://lime-technology.com/forum/index.php?topic=13440.0;wap2 It would be instructive to see what 'hdparm -N /dev/sdd' says on your system. And a dmesg log would be handy too. Note that this is /not/ a problem with xfs. The right fix is to tell the drive to report its actual capacity, not to shrink the filesystem. _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 14:12 ` Roger Willcocks @ 2012-01-24 15:46 ` Christian Kildau 2012-01-24 15:50 ` Eric Sandeen 0 siblings, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-24 15:46 UTC (permalink / raw) To: Roger Willcocks; +Cc: Eric Sandeen, xfs On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote: > > On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote: >> Top posting... sorry. >> >> I have now found dozens of other users with a similar issue! e.g. >> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ >> >> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). >> > > It seems fairly clear that your drive or the bios is lying about its > capacity. The filesystem occupies the entire disk, but the disk has > become 'smaller'. A quick web search suggests a 'hidden protected area' > - the two block counts in this link line up with the before and after > sizes you're seeing: > > http://lime-technology.com/forum/index.php?topic=13440.0;wap2 > > It would be instructive to see what 'hdparm -N /dev/sdd' says on your > system. And a dmesg log would be handy too. > > Note that this is /not/ a problem with xfs. The right fix is to tell the > drive to report its actual capacity, not to shrink the filesystem. I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches... I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd. XFS mounts without any problems and I can restore my data. Thanks all for your help! _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 15:46 ` Christian Kildau @ 2012-01-24 15:50 ` Eric Sandeen 2012-01-24 15:52 ` Christian Kildau 0 siblings, 1 reply; 21+ messages in thread From: Eric Sandeen @ 2012-01-24 15:50 UTC (permalink / raw) To: Christian Kildau; +Cc: Roger Willcocks, xfs On 1/24/12 9:46 AM, Christian Kildau wrote: > > On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote: > >> >> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote: >>> Top posting... sorry. >>> >>> I have now found dozens of other users with a similar issue! e.g. >>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ >>> >>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). >>> >> >> It seems fairly clear that your drive or the bios is lying about its >> capacity. The filesystem occupies the entire disk, but the disk has >> become 'smaller'. A quick web search suggests a 'hidden protected area' >> - the two block counts in this link line up with the before and after >> sizes you're seeing: >> >> http://lime-technology.com/forum/index.php?topic=13440.0;wap2 >> >> It would be instructive to see what 'hdparm -N /dev/sdd' says on your >> system. And a dmesg log would be handy too. >> >> Note that this is /not/ a problem with xfs. The right fix is to tell the >> drive to report its actual capacity, not to shrink the filesystem. > > I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches... > > I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd. > XFS mounts without any problems and I can restore my data. > > Thanks all for your help! It's likely still missing the end of the filesystem, though. Can you run the hdparm command Roger suggested on your original hard drive, please? _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 15:50 ` Eric Sandeen @ 2012-01-24 15:52 ` Christian Kildau 2012-01-24 15:57 ` Eric Sandeen 0 siblings, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-24 15:52 UTC (permalink / raw) To: Eric Sandeen; +Cc: Roger Willcocks, xfs On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote: > On 1/24/12 9:46 AM, Christian Kildau wrote: >> >> On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote: >> >>> >>> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote: >>>> Top posting... sorry. >>>> >>>> I have now found dozens of other users with a similar issue! e.g. >>>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ >>>> >>>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). >>>> >>> >>> It seems fairly clear that your drive or the bios is lying about its >>> capacity. The filesystem occupies the entire disk, but the disk has >>> become 'smaller'. A quick web search suggests a 'hidden protected area' >>> - the two block counts in this link line up with the before and after >>> sizes you're seeing: >>> >>> http://lime-technology.com/forum/index.php?topic=13440.0;wap2 >>> >>> It would be instructive to see what 'hdparm -N /dev/sdd' says on your >>> system. And a dmesg log would be handy too. >>> >>> Note that this is /not/ a problem with xfs. The right fix is to tell the >>> drive to report its actual capacity, not to shrink the filesystem. >> >> I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches... >> >> I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd. >> XFS mounts without any problems and I can restore my data. >> >> Thanks all for your help! > > It's likely still missing the end of the filesystem, though. > > Can you run the hdparm command Roger suggested on your original hard drive, please? Sure, here it is: /dev/sde: max sectors = 2930275055/2930277168, HPA is enabled _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 15:52 ` Christian Kildau @ 2012-01-24 15:57 ` Eric Sandeen 2012-01-24 17:25 ` Roger Willcocks 0 siblings, 1 reply; 21+ messages in thread From: Eric Sandeen @ 2012-01-24 15:57 UTC (permalink / raw) To: Christian Kildau; +Cc: xfs-oss On 1/24/12 9:52 AM, Christian Kildau wrote: > On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote: > >> On 1/24/12 9:46 AM, Christian Kildau wrote: >>> >>> On Jan 24, 2012, at 3:12 PM, Roger Willcocks wrote: >>> >>>> >>>> On Tue, 2012-01-24 at 11:13 +0100, Christian Kildau wrote: >>>>> Top posting... sorry. >>>>> >>>>> I have now found dozens of other users with a similar issue! e.g. >>>>> http://www.linuxquestions.org/questions/linux-general-1/cannot-mount-hard-disk-block-count-exceeds-size-of-device-bad-partition-table-880149/ >>>>> >>>>> To make it short all of these users were running ext4 and a fs resize to the new geometry fixed their problems! Sadly XFS doesn't support shrinking the fs(?). >>>>> >>>> >>>> It seems fairly clear that your drive or the bios is lying about its >>>> capacity. The filesystem occupies the entire disk, but the disk has >>>> become 'smaller'. A quick web search suggests a 'hidden protected area' >>>> - the two block counts in this link line up with the before and after >>>> sizes you're seeing: >>>> >>>> http://lime-technology.com/forum/index.php?topic=13440.0;wap2 >>>> >>>> It would be instructive to see what 'hdparm -N /dev/sdd' says on your >>>> system. And a dmesg log would be handy too. >>>> >>>> Note that this is /not/ a problem with xfs. The right fix is to tell the >>>> drive to report its actual capacity, not to shrink the filesystem. >>> >>> I do understand that is definitely not an XFS issue, but some strange issue with ubuntu or their kernel patches... >>> >>> I got my data back by dumping the entire hdd (it was partitionless nevertheless) to a bigger 2TB hdd. >>> XFS mounts without any problems and I can restore my data. >>> >>> Thanks all for your help! >> >> It's likely still missing the end of the filesystem, though. >> >> Can you run the hdparm command Roger suggested on your original hard drive, please? > > Sure, here it is: > > /dev/sde: > max sectors = 2930275055/2930277168, HPA is enabled ^^^^^^^^^^^^^^ ding ding ding, we have a winner. 2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end. Something about the ubuntu upgrade messed with your disk. I'd press them very hard to investigate & resolve that. You can probably use hdparm to remove the HPA and get your space back but this is beyond my expertise & familiarity. It'd be interesting to know what is _in_ the HPA area first. -Eric _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 15:57 ` Eric Sandeen @ 2012-01-24 17:25 ` Roger Willcocks 2012-01-24 18:10 ` Christian Kildau 0 siblings, 1 reply; 21+ messages in thread From: Roger Willcocks @ 2012-01-24 17:25 UTC (permalink / raw) To: Eric Sandeen; +Cc: xfs-oss, Christian Kildau On Tue, 2012-01-24 at 09:57 -0600, Eric Sandeen wrote: > On 1/24/12 9:52 AM, Christian Kildau wrote: > > On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote: > > ... > >> Can you run the hdparm command Roger suggested on your original hard drive, please? > > > > Sure, here it is: > > > > /dev/sde: > > max sectors = 2930275055/2930277168, HPA is enabled > ^^^^^^^^^^^^^^ > > ding ding ding, we have a winner. > > 2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end. > > Something about the ubuntu upgrade messed with your disk. > > I'd press them very hard to investigate & resolve that. You can probably use hdparm > to remove the HPA and get your space back but this is beyond my expertise & > familiarity. It'd be interesting to know what is _in_ the HPA area first. > Kernel commit d8d9129ea28e2177749627c82962feb26e8d11e9 added code to notice if a disk partition extends into the hidden area and 'unlocks' the hidden area (uses the full disk capacity) if necessary. But if there's no partition table (the entire disk is formatted as a single filesystem) the heuristic can't work. http://www.spinics.net/lists/linux-ide/msg40244.html suggests that Ubuntu no longer always unlocks, but uses the heuristic above. In the same message Alan Cox says Ubuntu 'made a bad mistake on that one.' -- Roger Willcocks <roger@filmlight.ltd.uk> _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-24 17:25 ` Roger Willcocks @ 2012-01-24 18:10 ` Christian Kildau 0 siblings, 0 replies; 21+ messages in thread From: Christian Kildau @ 2012-01-24 18:10 UTC (permalink / raw) To: Roger Willcocks; +Cc: Eric Sandeen, xfs-oss On Jan 24, 2012, at 6:25 PM, Roger Willcocks wrote: > > On Tue, 2012-01-24 at 09:57 -0600, Eric Sandeen wrote: >> On 1/24/12 9:52 AM, Christian Kildau wrote: >>> On Jan 24, 2012, at 4:50 PM, Eric Sandeen wrote: >>> > ... >>>> Can you run the hdparm command Roger suggested on your original hard drive, please? >>> >>> Sure, here it is: >>> >>> /dev/sde: >>> max sectors = 2930275055/2930277168, HPA is enabled >> ^^^^^^^^^^^^^^ >> >> ding ding ding, we have a winner. >> >> 2930277168-2930275055 = 2113 which is about how much xfs tried to read past the end. >> >> Something about the ubuntu upgrade messed with your disk. >> >> I'd press them very hard to investigate & resolve that. You can probably use hdparm >> to remove the HPA and get your space back but this is beyond my expertise & >> familiarity. It'd be interesting to know what is _in_ the HPA area first. >> > > Kernel commit d8d9129ea28e2177749627c82962feb26e8d11e9 added code to > notice if a disk partition extends into the hidden area and 'unlocks' > the hidden area (uses the full disk capacity) if necessary. > > But if there's no partition table (the entire disk is formatted as a > single filesystem) the heuristic can't work. > > http://www.spinics.net/lists/linux-ide/msg40244.html suggests that > Ubuntu no longer always unlocks, but uses the heuristic above. In the > same message Alan Cox says Ubuntu 'made a bad mistake on that one.' > > -- > Roger Willcocks <roger@filmlight.ltd.uk> > Good to know! Made me choose another OS for the next servers! Thanks _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-23 4:31 ` Dave Chinner 2012-01-23 9:23 ` Christian Kildau @ 2012-01-23 10:43 ` Christian Kildau 1 sibling, 0 replies; 21+ messages in thread From: Christian Kildau @ 2012-01-23 10:43 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs [-- Attachment #1: Type: text/plain, Size: 32 bytes --] Sorry, heres the right strace: [-- Attachment #2: xfs_check.strace --] [-- Type: application/octet-stream, Size: 3435 bytes --] execve("/usr/sbin/xfs_check", ["xfs_check", "/dev/sde"], [/* 20 vars */]) = 0 brk(0) = 0x13b9000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3935828000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0 mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3935822000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0 mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3935268000 mprotect(0x7f39353ff000, 2097152, PROT_NONE) = 0 mmap(0x7f39355ff000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7f39355ff000 mmap(0x7f3935604000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3935604000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3935821000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f393581f000 arch_prctl(ARCH_SET_FS, 0x7f393581f720) = 0 mprotect(0x7f39355ff000, 16384, PROT_READ) = 0 mprotect(0x619000, 4096, PROT_READ) = 0 mprotect(0x7f393582a000, 4096, PROT_READ) = 0 munmap(0x7f3935822000, 23783) = 0 getpid() = 11387 rt_sigaction(SIGCHLD, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0 geteuid() = 0 brk(0) = 0x13b9000 brk(0x13da000) = 0x13da000 getppid() = 11386 stat("/home/mrkofee", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...}) = 0 stat(".", {st_mode=S_IFDIR|S_ISGID|0770, st_size=4096, ...}) = 0 open("/usr/sbin/xfs_check", O_RDONLY) = 3 fcntl(3, F_DUPFD, 10) = 10 close(3) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x40f0e0, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f393529e430}, NULL, 8) = 0 read(10, "#!/bin/sh -f\n#\n# Copyright (c) 2"..., 8192) = 698 stat("/usr/local/sbin/xfs_db", 0x7fff67038140) = -1 ENOENT (No such file or directory) stat("/usr/local/bin/xfs_db", 0x7fff67038140) = -1 ENOENT (No such file or directory) stat("/usr/sbin/xfs_db", {st_mode=S_IFREG|0755, st_size=438344, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f393581f9f0) = 11388 wait4(-1, xfs_check: error - read only 0 of 512 bytes [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 11388 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigreturn(0x11) = 11388 exit_group(0) = ? [-- Attachment #3: xfs_repair.strace --] [-- Type: application/octet-stream, Size: 7959 bytes --] execve("/sbin/xfs_repair", ["xfs_repair", "/dev/sde"], [/* 20 vars */]) = 0 brk(0) = 0x846000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a0405000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=23783, ...}) = 0 mmap(NULL, 23783, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe7a03ff000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\25\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=18896, ...}) = 0 mmap(NULL, 2113944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79ffe2000 mprotect(0x7fe79ffe6000, 2093056, PROT_NONE) = 0 mmap(0x7fe7a01e5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7fe7a01e5000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200!\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=31752, ...}) = 0 mmap(NULL, 2128984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79fdda000 mprotect(0x7fe79fde1000, 2093056, PROT_NONE) = 0 mmap(0x7fe79ffe0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fe79ffe0000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240k\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=135217, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fe000 mmap(NULL, 2212888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79fbbd000 mprotect(0x7fe79fbd5000, 2093056, PROT_NONE) = 0 mmap(0x7fe79fdd4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fe79fdd4000 mmap(0x7fe79fdd6000, 13336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe79fdd6000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \24\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1689912, ...}) = 0 mmap(NULL, 3806024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe79f81b000 mprotect(0x7fe79f9b2000, 2097152, PROT_NONE) = 0 mmap(0x7fe79fbb2000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x197000) = 0x7fe79fbb2000 mmap(0x7fe79fbb7000, 21320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe79fbb7000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fd000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe7a03fb000 arch_prctl(ARCH_SET_FS, 0x7fe7a03fb760) = 0 mprotect(0x7fe79fbb2000, 16384, PROT_READ) = 0 mprotect(0x7fe79fdd4000, 4096, PROT_READ) = 0 mprotect(0x7fe79ffe0000, 4096, PROT_READ) = 0 mprotect(0x7fe7a01e5000, 4096, PROT_READ) = 0 mprotect(0x671000, 4096, PROT_READ) = 0 mprotect(0x7fe7a0407000, 4096, PROT_READ) = 0 munmap(0x7fe7a03ff000, 23783) = 0 set_tid_address(0x7fe7a03fba30) = 11699 set_robust_list(0x7fe7a03fba40, 0x18) = 0 futex(0x7fff0d90d54c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7fe7a03fb760) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7fe79fbc3680, [], SA_RESTORER|SA_SIGINFO, 0x7fe79fbccc10}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7fe79fbc3710, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fe79fbccc10}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x846000 brk(0x867000) = 0x867000 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2919792, ...}) = 0 mmap(NULL, 2919792, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe79f552000 close(3) = 0 getcwd("/home/mrkofee", 4096) = 14 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ustat(0x840, 0x7fff0d90bf80) = -1 EINVAL (Invalid argument) open("/dev/sde", O_RDONLY) = 3 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 stat("/dev/sde", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ustat(0x840, 0x7fff0d90bf80) = -1 EINVAL (Invalid argument) open("/dev/sde", O_RDWR|O_EXCL|O_DIRECT) = 4 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 fstat(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 64), ...}) = 0 ioctl(4, BLKGETSIZE64, 0x7fff0d90c0f0) = 0 ioctl(4, BLKSSZGET, 0x6732e0) = 0 chdir("/home/mrkofee") = 0 brk(0x888000) = 0x888000 close(3) = 0 getrlimit(RLIMIT_FSIZE, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 time(NULL) = 1327315350 time(NULL) = 1327315350 open("/usr/share/locale/locale.alias", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f551000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2570 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fe79f551000, 4096) = 0 open("/usr/share/locale/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en_US/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale-langpack/en/LC_MESSAGES/xfsprogs.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Phase 1 - find and verify superb"..., 40Phase 1 - find and verify superblock... ) = 40 mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f4d1000 mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fe79f450000 lseek(4, 0, SEEK_SET) = 0 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 524288) = 524288 munmap(0x7fe79f450000, 528384) = 0 brk(0x8be000) = 0x8be000 lseek(4, 375075479552, SEEK_SET) = 375075479552 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 lseek(4, 750150959104, SEEK_SET) = 750150959104 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 lseek(4, 1125226438656, SEEK_SET) = 1125226438656 read(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072 munmap(0x7fe79f4d1000, 528384) = 0 time(NULL) = 1327315350 pread(4, "XFSB\0\0\20\0\0\0\0\0\25\325\17f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32768, 0) = 32768 pread(4, "", 512, 1500301909504) = 0 write(2, "xfs_repair: error - read only 0 "..., 45xfs_repair: error - read only 0 of 512 bytes ) = 45 exit_group(1) = ? [-- Attachment #4: Type: text/plain, Size: 1642 bytes --] All other output was correct! On Jan 23, 2012, at 5:31 AM, Dave Chinner wrote: > On Sat, Jan 21, 2012 at 11:29:15AM +0100, Christian Kildau wrote: >> Sorry if this message appears twice! >> >> >> >> Hello, >> >> I'm having some very serious issues with XFS after upgrading from a >> Linux Distro running Ubuntu 2.6.32 to 3.2. >> >> It seems like my filesystems are damaged after attaching them to a >> Linux 3.2 server. I am also no longer able to mount the hdd on the old >> server that is still running 2.6.32! > > I take it that you are using external storage of some kind? Can you > describe it? > >> (I created the xfs filesystem on the entire hdd, not on a partition, >> so /dev/sdd is not a typo) >> >> $ sudo mount -t xfs /dev/sdd /media/ >> mount: /dev/sdd: can't read superblock >> (dmesg) >> [236659.912663] attempt to access beyond end of device >> [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 >> [236659.912670] XFS (sdd): last sector read failed > > So XFS has asked to read 2113 sectors beyond the size of the device > that the kernel is reporting. What is the output of > /proc/partitions? > >> $ sudo xfs_check /dev/sdd >> xfs_check: error - read only 0 of 512 bytes >> >> $ sudo xfs_repair /dev/sdd >> Phase 1 - find and verify superblock... >> xfs_repair: error - read only 0 of 512 bytes > > So both buffered and direct IO to the first block in the block > device are failing. I'd say your problems have nothing to do with > XFS. However, can you strace them and find out what the error that > is occuring actually is? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com [-- Attachment #5: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes
@ 2019-12-28 11:11 Utpal Bora
2019-12-29 3:15 ` Chris Murphy
2019-12-29 4:43 ` Eric Sandeen
0 siblings, 2 replies; 21+ messages in thread
From: Utpal Bora @ 2019-12-28 11:11 UTC (permalink / raw)
To: linux-xfs
Hi,
My XFS home drive is corrupt after trying to extend it with lvm.
This is what I did to extend the partition.
1. Extend Volume group to use a new physical volume of around 1.2TB.
This was successful without any error.
vgextend vg-1 /dev/sdc1
2. Extend logical volume (home-lv) to use the free space.
lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r
3. Resized home-lv and reduce 55 GB
lvreduce -L 55G /dev/mapper/vg--1-home--lv -r
I assumed that -r will invoke xfs_grow internally.
Everything was working fine until the server was restarted.
After restart, the home volume is not mounting. Please see the following.
server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home
mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv.
server% dmesg| tail
[162580.208796] attempt to access beyond end of device
[162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560
[162580.208805] XFS (dm-3): last sector read failed
server% sudo xfs_repair -n /dev/mapper/vg--1-home--lv
Phase 1 - find and verify superblock...
xfs_repair: error - read only 0 of 512 bytes
OS: Ubuntu Server 18.04.3
Kernel: 4.15.0-72-generic
I have gone through the earlier posts on this subject. They did not help me.
Is it possible to repair the XFS volume? Kindly suggest.
Regards,
Utpal Bora
Ph.D. Scholar
Computer Science & Engineering
IIT Hyderabad
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2019-12-28 11:11 Utpal Bora @ 2019-12-29 3:15 ` Chris Murphy 2019-12-29 5:58 ` Utpal Bora 2019-12-29 4:43 ` Eric Sandeen 1 sibling, 1 reply; 21+ messages in thread From: Chris Murphy @ 2019-12-29 3:15 UTC (permalink / raw) To: Utpal Bora; +Cc: xfs list On Sat, Dec 28, 2019 at 4:12 AM Utpal Bora <cs14mtech11017@iith.ac.in> wrote: > > Hi, > > My XFS home drive is corrupt after trying to extend it with lvm. > This is what I did to extend the partition. > 1. Extend Volume group to use a new physical volume of around 1.2TB. > This was successful without any error. > vgextend vg-1 /dev/sdc1 > > 2. Extend logical volume (home-lv) to use the free space. > lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r What approximate byte value is 100%FREE ? > 3. Resized home-lv and reduce 55 GB > lvreduce -L 55G /dev/mapper/vg--1-home--lv -r If this is really a volume reduction, along with -r I would expect this entire command to fail. XFS doesn't support shrink. Since a successful LV shrink requires shrinking the file system first, or else it results in truncation of the file system it contains and thus damages it, off hand I think this is a bug in lvreduce, or possibly in fsadm which is what -r calls to do the resize. My suggestion is to make no further changes at all, no further recovery attempts. And head over to the LVM list and make the same post as above. It's very possible there's backup LVM metadata that will reference the PE/LE's used in the LV prior to the lvreduce. By restoring the LV using that exact same mapping, it should be possible to recover the file system it contains. But only if you don't make other attempts. The more additional attempts the greater the chance of irreparable changes. https://www.redhat.com/mailman/listinfo/linux-lvm > I assumed that -r will invoke xfs_grow internally. Right, but xfs_grow only grows. It doesn't shrink. So my expectation is that the lvreduce command should fail without having made any changes. And yet... -- Chris Murphy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2019-12-29 3:15 ` Chris Murphy @ 2019-12-29 5:58 ` Utpal Bora 0 siblings, 0 replies; 21+ messages in thread From: Utpal Bora @ 2019-12-29 5:58 UTC (permalink / raw) To: Chris Murphy; +Cc: xfs list Hello Chris, Thank you for your response. I could solve the problem by extending the lv as Eric suggested. Regards, Utpal Bora Ph.D. Scholar Computer Science & Engineering IIT Hyderabad http://utpalbora.com PGP key fingerprint: 2F12 635E 409F 11AC 1502 BB41 7705 9980 A062 FA70 On Sun, Dec 29, 2019 at 8:45 AM Chris Murphy <lists@colorremedies.com> wrote: > > On Sat, Dec 28, 2019 at 4:12 AM Utpal Bora <cs14mtech11017@iith.ac.in> wrote: > > > > Hi, > > > > My XFS home drive is corrupt after trying to extend it with lvm. > > This is what I did to extend the partition. > > 1. Extend Volume group to use a new physical volume of around 1.2TB. > > This was successful without any error. > > vgextend vg-1 /dev/sdc1 > > > > 2. Extend logical volume (home-lv) to use the free space. > > lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r > > What approximate byte value is 100%FREE ? > > > 3. Resized home-lv and reduce 55 GB > > lvreduce -L 55G /dev/mapper/vg--1-home--lv -r > > If this is really a volume reduction, along with -r I would expect > this entire command to fail. XFS doesn't support shrink. Since a > successful LV shrink requires shrinking the file system first, or else > it results in truncation of the file system it contains and thus > damages it, off hand I think this is a bug in lvreduce, or possibly in > fsadm which is what -r calls to do the resize. > > My suggestion is to make no further changes at all, no further > recovery attempts. And head over to the LVM list and make the same > post as above. It's very possible there's backup LVM metadata that > will reference the PE/LE's used in the LV prior to the lvreduce. By > restoring the LV using that exact same mapping, it should be possible > to recover the file system it contains. But only if you don't make > other attempts. The more additional attempts the greater the chance of > irreparable changes. > > https://www.redhat.com/mailman/listinfo/linux-lvm > > > I assumed that -r will invoke xfs_grow internally. > > Right, but xfs_grow only grows. It doesn't shrink. So my expectation > is that the lvreduce command should fail without having made any > changes. And yet... > > -- > Chris Murphy ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2019-12-28 11:11 Utpal Bora 2019-12-29 3:15 ` Chris Murphy @ 2019-12-29 4:43 ` Eric Sandeen 2019-12-29 5:58 ` Utpal Bora 1 sibling, 1 reply; 21+ messages in thread From: Eric Sandeen @ 2019-12-29 4:43 UTC (permalink / raw) To: Utpal Bora; +Cc: linux-xfs On Dec 28, 2019, at 3:11 AM, Utpal Bora <cs14mtech11017@iith.ac.in> wrote: > > Hi, > > My XFS home drive is corrupt after trying to extend it with lvm. > This is what I did to extend the partition. > 1. Extend Volume group to use a new physical volume of around 1.2TB. > This was successful without any error. > vgextend vg-1 /dev/sdc1 > > 2. Extend logical volume (home-lv) to use the free space. > lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r > This probably invoked xfs_growfs > 3. Resized home-lv and reduce 55 GB > lvreduce -L 55G /dev/mapper/vg--1-home--lv -r > XFS cannot shrink. This corrupted your filesystem by truncating the block device. > I assumed that -r will invoke xfs_grow internally. > Everything was working fine until the server was restarted. > After restart, the home volume is not mounting. Please see the following. > > server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home > mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv. > > server% dmesg| tail > [162580.208796] attempt to access beyond end of device > [162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560 > [162580.208805] XFS (dm-3): last sector read failed Because you chopped off 55g from the end. > server% sudo xfs_repair -n Repair cannot read blocks that have been removed from the filesystem. > /dev/mapper/vg--1-home--lv > Phase 1 - find and verify superblock... > xfs_repair: error - read only 0 of 512 bytes Failed to read a backup super beyond the end of the reduced lv. Grow the lv back to 100% I.e. the size before the lvreduce and it’ll probably be ok again -Eric > OS: Ubuntu Server 18.04.3 > Kernel: 4.15.0-72-generic > > I have gone through the earlier posts on this subject. They did not help me. > > Is it possible to repair the XFS volume? Kindly suggest. > > Regards, > > Utpal Bora > Ph.D. Scholar > Computer Science & Engineering > IIT Hyderabad > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2019-12-29 4:43 ` Eric Sandeen @ 2019-12-29 5:58 ` Utpal Bora 0 siblings, 0 replies; 21+ messages in thread From: Utpal Bora @ 2019-12-29 5:58 UTC (permalink / raw) To: Eric Sandeen; +Cc: linux-xfs Hi Eric, Thank you for your help. Growing back lv to original size helped. I am really thankful. Is there a way for lvm to warn users while invoking lvreduce to check if the file system should be shrunk before lvreduce. Regards, Utpal Bora Ph.D. Scholar Computer Science & Engineering IIT Hyderabad http://utpalbora.com PGP key fingerprint: 2F12 635E 409F 11AC 1502 BB41 7705 9980 A062 FA70 Regards, Utpal Bora Ph.D. Scholar Computer Science & Engineering IIT Hyderabad http://utpalbora.com PGP key fingerprint: 2F12 635E 409F 11AC 1502 BB41 7705 9980 A062 FA70 On Sun, Dec 29, 2019 at 10:13 AM Eric Sandeen <sandeen@sandeen.net> wrote: > > On Dec 28, 2019, at 3:11 AM, Utpal Bora <cs14mtech11017@iith.ac.in> wrote: > > > > Hi, > > > > My XFS home drive is corrupt after trying to extend it with lvm. > > This is what I did to extend the partition. > > 1. Extend Volume group to use a new physical volume of around 1.2TB. > > This was successful without any error. > > vgextend vg-1 /dev/sdc1 > > > > 2. Extend logical volume (home-lv) to use the free space. > > lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r > > > This probably invoked xfs_growfs > > > 3. Resized home-lv and reduce 55 GB > > lvreduce -L 55G /dev/mapper/vg--1-home--lv -r > > > XFS cannot shrink. This corrupted your filesystem by truncating the block device. > > > I assumed that -r will invoke xfs_grow internally. > > Everything was working fine until the server was restarted. > > After restart, the home volume is not mounting. Please see the following. > > > > server% sudo mount -t xfs /dev/mapper/vg--1-home--lv /home > > mount: /home: can't read superblock on /dev/mapper/vg--1-home--lv. > > > > server% dmesg| tail > > [162580.208796] attempt to access beyond end of device > > [162580.208800] dm-3: rw=4096, want=6650552320, limit=6640066560 > > [162580.208805] XFS (dm-3): last sector read failed > > Because you chopped off 55g from the end. > > > server% sudo xfs_repair -n > > Repair cannot read blocks that have been removed from the filesystem. > > > > /dev/mapper/vg--1-home--lv > > Phase 1 - find and verify superblock... > > xfs_repair: error - read only 0 of 512 bytes > > Failed to read a backup super beyond the end of the reduced lv. > > Grow the lv back to 100% I.e. the size before the lvreduce and it’ll probably be ok again > > -Eric > > > OS: Ubuntu Server 18.04.3 > > Kernel: 4.15.0-72-generic > > > > I have gone through the earlier posts on this subject. They did not help me. > > > > Is it possible to repair the XFS volume? Kindly suggest. > > > > Regards, > > > > Utpal Bora > > Ph.D. Scholar > > Computer Science & Engineering > > IIT Hyderabad > > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes @ 2012-01-21 10:03 Christian Kildau 2012-01-24 4:51 ` Eric Sandeen 0 siblings, 1 reply; 21+ messages in thread From: Christian Kildau @ 2012-01-21 10:03 UTC (permalink / raw) To: xfs Hello, I'm having some very serious issues with XFS after upgrading from a Linux Distro running Ubuntu 2.6.32 to 3.2. It seems like my filesystems are damaged after attaching them to a Linux 3.2 server. I am also no longer able to mount the hdd on the old server that is still running 2.6.32! 'test disk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd. (I created the xfs filesystem on the entire hdd, not on a partition, so /dev/sdd is not a typo) $ sudo mount -t xfs /dev/sdd /media/ mount: /dev/sdd: can't read superblock (dmesg) [236659.912663] attempt to access beyond end of device [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 [236659.912670] XFS (sdd): last sector read failed $ sudo xfs_check /dev/sdd xfs_check: error - read only 0 of 512 bytes $ sudo xfs_repair /dev/sdd Phase 1 - find and verify superblock... xfs_repair: error - read only 0 of 512 bytes 'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd. Is there any way I can fix this? - Except restroring from backup? Because this IS my backup! see ubuntuforums.org/showthread.php?t=1910962 for more details… Any help is appreciated! Thanks in advance Chris _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes 2012-01-21 10:03 Christian Kildau @ 2012-01-24 4:51 ` Eric Sandeen 0 siblings, 0 replies; 21+ messages in thread From: Eric Sandeen @ 2012-01-24 4:51 UTC (permalink / raw) To: Christian Kildau; +Cc: xfs On 1/21/12 4:03 AM, Christian Kildau wrote: > Hello, > > I'm having some very serious issues with XFS after upgrading from a > Linux Distro running Ubuntu 2.6.32 to 3.2. > > It seems like my filesystems are damaged after attaching them to a > Linux 3.2 server. I am also no longer able to mount the hdd on the > old server that is still running 2.6.32! did you do anything else at all besides simply boot a 3.2 kernel? Or was this a whole distro upgrade? And who knows what the installer did...? > 'test disk' does find the filesystem as XFS 4 and i created a 1.5TB > dump of it to another hdd. > > (I created the xfs filesystem on the entire hdd, not on a partition, > so /dev/sdd is not a typo) is sdd a single disk or something like lvm/md? what does grep sdd /proc/partitions say? And # xfs_db -c "sb 0" -c "p" /dev/sdd > > $ sudo mount -t xfs /dev/sdd /media/ > mount: /dev/sdd: can't read superblock > (dmesg) > [236659.912663] attempt to access beyond end of device > [236659.912667] sdd: rw=32, want=2930277168, limit=2930275055 > [236659.912670] XFS (sdd): last sector read failed > > $ sudo xfs_check /dev/sdd > xfs_check: error - read only 0 of 512 bytes > > $ sudo xfs_repair /dev/sdd > Phase 1 - find and verify superblock... > xfs_repair: error - read only 0 of 512 bytes stracing those to see where it is failing to read might be useful. It seems that your device has somehow shrunk out from under your fs. -Eric > > 'testdisk' does find the filesystem as XFS 4 and i created a 1.5TB dump of it to another hdd. > > Is there any way I can fix this? - Except restroring from backup? Because this IS my backup! > see ubuntuforums.org/showthread.php?t=1910962 for more details… > > > Any help is appreciated! > > Thanks in advance > Chris > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-12-29 5:59 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-01-21 10:29 How to fix bad superblock or xfs_repair: error - read only 0 of 512 bytes Christian Kildau 2012-01-23 4:31 ` Dave Chinner 2012-01-23 9:23 ` Christian Kildau 2012-01-24 5:04 ` Eric Sandeen 2012-01-24 7:08 ` Christian Kildau 2012-01-24 10:13 ` Christian Kildau 2012-01-24 14:12 ` Roger Willcocks 2012-01-24 15:46 ` Christian Kildau 2012-01-24 15:50 ` Eric Sandeen 2012-01-24 15:52 ` Christian Kildau 2012-01-24 15:57 ` Eric Sandeen 2012-01-24 17:25 ` Roger Willcocks 2012-01-24 18:10 ` Christian Kildau 2012-01-23 10:43 ` Christian Kildau -- strict thread matches above, loose matches on Subject: below -- 2019-12-28 11:11 Utpal Bora 2019-12-29 3:15 ` Chris Murphy 2019-12-29 5:58 ` Utpal Bora 2019-12-29 4:43 ` Eric Sandeen 2019-12-29 5:58 ` Utpal Bora 2012-01-21 10:03 Christian Kildau 2012-01-24 4:51 ` Eric Sandeen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).