Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thanks for all hints and help.
Actually true, It was force shutdown/reboot of system which was causing
xfs_check to fail. once i do normal reboot it worked fine. to prove it i
also tried mount it and umount back and do xfs_check and it worked this
time didn't crib. Thanks you all.
Appreciate your help.
-Fazor
On Mon, Nov 23, 2015 at 4:50 PM, Lars Ellenberg <lars.ellenberg at linbit.com>
wrote:
> On Fri, Nov 20, 2015 at 06:23:16PM +0530, Ajay Yadav wrote:
> > Hi,
> > i have DRBD device working on lvm which is of type xfs. when i run
> > xfs_check on this volume it always fails with error
>
> Does not necessarily have something to do with DRBD.
>
> XFS went bad on me on some file systems, without DRBD involved,
> all healthy hardware and no crashes, all "by itself".
> (Though some strange NFS setup was involved, maybe there was bad
> interaction. We never really found out what caused the corruption.)
>
> That said, XFS is my preferred file system, both with and without DRBD.
>
> In my experience, when XFS feels "corrupt", most of the time there had
> been volatile caches (on-disk write buffers) and hard crashes involved.
> Don't do that.
>
> > #xfs_check /dev/vg1/lv_data
> > 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_check.
>
> So: are you able to mount, then umount it?
>
> If so: it was simply not cleanly unmounted (crashed while being busy),
> and that is all xfs_check complains about.
>
> "Normal behaviour."
>
> That's what the journal was designed for.
> mount will do the journal replay/recovery, and all is well.
>
>
> > If you are unable to mount the filesystem, then use
> > the xfs_repair -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.
> >
> > then if i repair, it i needed to xfs_repair with -L option which is not
> > suggested.
> >
> > i can do repair but the real issue is on every boot xfs_check fails and
> it
> > asks for repair with -L L.
>
> In case you are *NOT* able to mount it, and you are already desperate to
> get at the data, even just for "recovery":
> many times you still can do a read-only mount ("mount -o ro").
>
> > please let me know if you want me to check anything.
> > My DRBD version is: 8.4.4
> >
> > i have other non drbd xfs volumes which work just fine with xfs_check.
> >
> > Thanks,
> > Fazor
>
> --
> : Lars Ellenberg
> : http://www.LINBIT.com | Your Way to High Availability
> : DRBD, Linux-HA and Pacemaker support and consulting
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
> __
> please don't Cc me, but send to list -- I'm subscribed
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20151123/7d88dc63/attachment.htm>