-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2014-07-11 at 15:31 -0700, Linda Walsh wrote:
Carlos E. R. wrote:
The last message on this thread on the xfs list was about 5-6 days ago.
I just posted another one that was pending, I had forgotten till I saw yours. I sent them the link to the metadata, but I'm afraid it will not help, because it is not "corrupt". We have to wait till the event happens again, and then I take a photo before repairing the filesystem. I can not even allow it to mount, because that replays the log. Unless the corruption is one simply not detected, till the filesystem crashes.
Any luck in finding this?
For those here, the XFS people think that the culprit is the kernel, that does not restore properly all memory structures used by the XFS filesystem. The suggestion is not to hibernate till the kernel people solve hibernation once and for all - or so I understood.
BTW... is your new disk an advanced-format, 512e, or 4096k sector size?
Dunno... Wait. This was the original filesystem, as copied: meta-data=/dev/sdf2 isize=256 agcount=4, agsize=122341568 blks = sectsz=512 attr=2 data = bsize=4096 blocks=489366272, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=238948, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 And this is the current one: meta-data=/dev/sde5 isize=256 agcount=4, agsize=32000000 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 data = bsize=4096 blocks=128000000, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=62500, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Something wrong... data size do not match. [...] Oops. The first xfs_info belongs to the wrong one. I'm very confused. See note on the other list. It is as is when I do "xfs_info tgtfile" it is done on the the device where the file is stored, not on the file. Wow, that's it... Look, with the exact same file, copied on two partitions: Telcontar:/data/storage_c/tmp_borrar # xfs_info tgtfile meta-data=/dev/sde18 isize=256 agcount=4, agsize=35770496 blks = sectsz=512 attr=2, projid32bit=0 = crc=0 data = bsize=4096 blocks=143081984, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=69864, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Telcontar:/data/storage_c/tmp_borrar # Telcontar:/data/storage_d/old_backup # xfs_info tgtfile meta-data=/dev/sdf2 isize=256 agcount=4, agsize=122341568 blks = sectsz=512 attr=2, projid32bit=0 = crc=0 data = bsize=4096 blocks=489366272, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal bsize=4096 blocks=238948, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Telcontar:/data/storage_d/old_backup # False alarm. I need sleep. :-(
p.s. as a workaround -- in your "hibernate script", is it remotely possible to init down to some state to allow unmounting /home before the hibernate? It's a gross workaround, and likely not workable, but thought I'd ask.
I don't see how... home can not be umounted at all while in use. Synced to disk, I hope it is already done.
Is /home an lvm volume?..
Nay, it is not.
That could be helpful or a cause, but for helpful, creating a snapshot before hibernating might help protect against data loss...
So far, there is not been data loss. I can make an xfsdump, which is reasonably fast - for a partition so big. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlPAkdQACgkQtTMYHG2NR9VfywCfadZW35Q/ERfLTaXl8u29Xyo0 VBMAn1rm7I2uv470zmuilr6fN0cjj1GE =KTtW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org