[linux-lvm] Lvm think provisioning query
Zdenek Kabelac
zkabelac at redhat.com
Tue May 3 09:54:56 UTC 2016
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/
>
More information about the linux-lvm
mailing list