<div dir="ltr"><div><div>Does this mean the ext4 is showing wrong information. The file is reported being 90+MB but in actuality the size is less in the FS ?<br></div></div><div>This is quite ok because it is just that file system being affected. I was however concerned that the file in this FS might have overwritten other LV data since the file is showing bigger than the volume size. <br><br></div><div>I will try this using BTRFS.<br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 10:13 AM, Zdenek Kabelac <span dir="ltr"><<a href="mailto:zkabelac@redhat.com" target="_blank">zkabelac@redhat.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 28.4.2016 16:36, Bhasker C V wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Zdenek,<br>
  Thanks. Here I am just filling it up with random data and so I am not<br>
concerned about data integrity<br>
  You are right, I did get page lost during write errors in the kernel<br>
<br>
The question however is even after reboot and doing several fsck of the ext4fs<br>
the file size "occupied" is more than the pool size. How is this ?<br>
I agree that data may be corrupted, but there *is* some data and this must be<br>
saved somewhere. Why is this "somewhere" exceeding the pool size ?<br>
</blockquote>
<br></span>
Hi<br>
<br>
Few key principles -<br>
<br>
<br>
1. You should always mount extX fs with  errors=remount-ro  (tune2fs,mount)<br>
<br>
2. There are few data={} modes ensuring various degree of data integrity,<br>
   An case you really care about data integrity here - switch to 'journal'<br>
   mode at price of lower speed. Default ordered mode might show this.<br>
   (i.e. it's the very same behavior as you would have seen with failing hdd)<br>
<br>
3. Do not continue using thin-pool when it's full :)<br>
<br>
4. We do miss more configurable policies with thin-pools.<br>
   i.e. do plan to instantiate 'error' target for writes in the case<br>
   pool gets full - so ALL writes will be errored - as of now - writes<br>
   to provisioned blocks may cause further filesystem confusion - that's<br>
   why  'remount-ro' is rather mandatory - xfs is recently being enhanced<br>
   to provide similar logic.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Regards<br>
<br>
<br>
Zdenek<br>
<br>
_______________________________________________<br>
linux-lvm mailing list<br>
<a href="mailto:linux-lvm@redhat.com" target="_blank">linux-lvm@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-lvm" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/linux-lvm</a><br>
read the LVM HOW-TO at <a href="http://tldp.org/HOWTO/LVM-HOWTO/" rel="noreferrer" target="_blank">http://tldp.org/HOWTO/LVM-HOWTO/</a><br>
</div></div></blockquote></div><br></div>