[linux-lvm] Lvm think provisioning query

Tue May 3 12:21:27 UTC 2016

Here are the answers to your questions

1. fsck does not report any error and the file contained inside the FS is
definitely greater than the allocatable LV size
# fsck.ext4 -f -C0 /dev/virtp/vol01
e2fsck 1.43-WIP (15-Mar-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory
structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/virtp/vol01: 12/65536 files (8.3% non-contiguous), 30492/262144
blocks

2. Size of the file

# du -hs fil
69M     fil

(please note here that the LV virtual size is 1G but the parent pool size
is just 40M I expect the file not to exceed 40M at any cost.)

3. lvs
# lvs
  LV       VG    Attr       LSize  Pool     Origin Data%  Meta%  Move Log
Cpy%Sync Convert
  virtpool virtp twi-aotzD- 40.00m                 100.00
1.37
  vol01    virtp Vwi-aotz--  1.00g
virtpool

You can do this on any virtual machine. I use qemu with virtio back-end.

On Tue, May 3, 2016 at 11:54 AM, Zdenek Kabelac <zkabelac at redhat.com> wrote:

> On 3.5.2016 08:59, Bhasker C V wrote:
>
>> 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 ?
>> 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.
>>
>>
> I've no idea what 'ext4' is showing you, but if you have i.e. 100M
> filesystem size, you could still have there e.g. 1TB file. Experience the
> magic:
>
> 'truncate -s 1T myfirst1TBfile'
>
> As you can see 'ext4' is doing it's own over-provisioning with 'hole'
> files.
> The only important bits are:
> - is the filesystem consistent ?
> - is 'fsck' not reporting any error ?
>
> What's the 'real' size you get with 'du  myfirst1TBfile' or your wrong
> file ?
>
> Somehow I don't believe you can get  i.e.  90+MB 'du' size with 10MB
> filesystem size and 'fsck' would not report any problem.
>
> I will try this using BTRFS.
>>
>
> For what exactly ??
>
> Regard
>
> Zdenek
>
>
>
>
>
>>
>> On Fri, Apr 29, 2016 at 10:13 AM, Zdenek Kabelac <zkabelac at redhat.com
>> <mailto:zkabelac at redhat.com>> wrote:
>>
>>     On 28.4.2016 16:36, Bhasker C V wrote:
>>
>>         Zdenek,
>>            Thanks. Here I am just filling it up with random data and so I
>> am not
>>         concerned about data integrity
>>            You are right, I did get page lost during write errors in the
>> kernel
>>
>>         The question however is even after reboot and doing several fsck
>> of
>>         the ext4fs
>>         the file size "occupied" is more than the pool size. How is this ?
>>         I agree that data may be corrupted, but there *is* some data and
>> this
>>         must be
>>         saved somewhere. Why is this "somewhere" exceeding the pool size ?
>>
>>
>>     Hi
>>
>>     Few key principles -
>>
>>
>>     1. You should always mount extX fs with  errors=remount-ro
>> (tune2fs,mount)
>>
>>     2. There are few data={} modes ensuring various degree of data
>> integrity,
>>         An case you really care about data integrity here - switch to
>> 'journal'
>>         mode at price of lower speed. Default ordered mode might show
>> this.
>>         (i.e. it's the very same behavior as you would have seen with
>> failing hdd)
>>
>>     3. Do not continue using thin-pool when it's full :)
>>
>>     4. We do miss more configurable policies with thin-pools.
>>         i.e. do plan to instantiate 'error' target for writes in the case
>>         pool gets full - so ALL writes will be errored - as of now -
>> writes
>>         to provisioned blocks may cause further filesystem confusion -
>> that's
>>         why  'remount-ro' is rather mandatory - xfs is recently being
>> enhanced
>>         to provide similar logic.
>>
>>
>>
>>     Regards
>>
>>
>>     Zdenek
>>
>>     _______________________________________________
>>     linux-lvm mailing list
>>     linux-lvm at redhat.com <mailto:linux-lvm at redhat.com>
>>     https://www.redhat.com/mailman/listinfo/linux-lvm
>>     read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
>>
>>
>> _______________________________________________
>> linux-lvm mailing list
>> linux-lvm at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-lvm
>> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>>
>>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20160503/0ff0d5e6/attachment.htm>