<div dir="ltr">Thanks for all hints and help.<div>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. </div><div>Appreciate your help.</div><div>-Fazor<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 4:50 PM, Lars Ellenberg <span dir="ltr"><<a href="mailto:lars.ellenberg@linbit.com" target="_blank">lars.ellenberg@linbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Nov 20, 2015 at 06:23:16PM +0530, Ajay Yadav wrote:<br>
> Hi,<br>
> i have DRBD device working on lvm which is of type xfs. when i run<br>
> xfs_check on this volume it always fails with error<br>
<br>
</span>Does not necessarily have something to do with DRBD.<br>
<br>
XFS went bad on me on some file systems, without DRBD involved,<br>
all healthy hardware and no crashes, all "by itself".<br>
(Though some strange NFS setup was involved, maybe there was bad<br>
interaction. We never really found out what caused the corruption.)<br>
<br>
That said, XFS is my preferred file system, both with and without DRBD.<br>
<br>
In my experience, when XFS feels "corrupt", most of the time there had<br>
been volatile caches (on-disk write buffers) and hard crashes involved.<br>
Don't do that.<br>
<span class=""><br>
> #xfs_check /dev/vg1/lv_data<br>
> ERROR: The filesystem has valuable metadata changes in a log which needs to<br>
> be replayed. Mount the filesystem to replay the log, and unmount it before<br>
> re-running xfs_check.<br>
<br>
</span>So: are you able to mount, then umount it?<br>
<br>
If so: it was simply not cleanly unmounted (crashed while being busy),<br>
and that is all xfs_check complains about.<br>
<br>
"Normal behaviour."<br>
<br>
That's what the journal was designed for.<br>
mount will do the journal replay/recovery, and all is well.<br>
<span class=""><br>
<br>
> If you are unable to mount the filesystem, then use<br>
> the xfs_repair -L option to destroy the log and attempt a repair.<br>
> Note that destroying the log may cause corruption -- please attempt a mount<br>
> of the filesystem before doing this.<br>
><br>
> then if i repair, it i needed to xfs_repair with -L option which is not<br>
> suggested.<br>
><br>
> i can do repair but the real issue is on every boot xfs_check fails and it<br>
> asks for repair with -L L.<br>
<br>
</span>In case you are *NOT* able to mount it, and you are already desperate to<br>
get at the data, even just for "recovery":<br>
many times you still can do a read-only mount ("mount -o ro").<br>
<span class="im HOEnZb"><br>
> please let me know if you want me to check anything.<br>
> My DRBD version is: 8.4.4<br>
><br>
> i have other non drbd xfs volumes which work just fine with xfs_check.<br>
><br>
> Thanks,<br>
> Fazor<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
: Lars Ellenberg<br>
: <a href="http://www.LINBIT.com" rel="noreferrer" target="_blank">http://www.LINBIT.com</a> | Your Way to High Availability<br>
: DRBD, Linux-HA and Pacemaker support and consulting<br>
<br>
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.<br>
__<br>
please don't Cc me, but send to list -- I'm subscribed<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br>
<a href="http://lists.linbit.com/mailman/listinfo/drbd-user" rel="noreferrer" target="_blank">http://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
</div></div></blockquote></div><br></div></div></div>