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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.redhat.com/mailman/listinfo/linux-lvm >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >> >> >> >> >> _______________________________________________ >> linux-lvm mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/linux-lvm >> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >> >> > _______________________________________________ > linux-lvm mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ >
_______________________________________________ linux-lvm mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
