On 3.5.2016 14:21, Bhasker C V wrote:
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.
But this is VERY different case.
You filesystem IS 1GB in size and ext4 provisions mostly all 'metadatata'
during first mount.
So thin-pool has usually all filesystem's metadata space 'available' for
updating and if you use mount option data=ordered (being default) - it
happens that 'write' to provisioned space is OK, while write to 'data' space
gets async page lost.
And this all depends how are you willing to write your data.
Basically if you use page-cache and ignore 'fdatasync()' you NEVER know what
has been stored in disk (living in a dreamworld basically)
(i.e. close of your program/file descriptor DOES NOT flush)
When thin-pool gets full and you have not managed to resize your data LV
in-time various thing may go wrong - this is a fuzzy tricky land.
Now few people (me included) believe thin volume should error 'ANY' further
write when there was an overprovisioning error on a device and I'm afraid this
can't be solved elsewhere then in target driver.
ATM this thin volume puts filesystem into very complex situation which does
not have 'winning' scenario in number of cases - so we need to define number
of policies.
BUT ATM we clearly communicate - when you run OUT of thin-pool space
it's serious ADMIN failure - and we could only try to lower damage.
Thin-pool overfull CANNOT be compared to writing to a full filesystem
and there is absolutely no guarantee about content of non-flushed files!
Expecting you run out-of-space in thin-pool and nothing bad can happens is
naive ATM - we are cooperating at least with XFS/ext4 developers to solve some
corner case, but there is still a lot of work to do as we exercise quite
unusual error paths for them.
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
