With 64k block size, 200MiB disk space is not sufficient to create an
XFS filesystem. Hence this commit increases the size of the
overprovisioned dm-thin device to 300MiB. The commit also increases the
other associated disk sizes (original physical size and new physical
size) appropriately.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Currently ,freeze failure caused by the lack of space can not
guarantee to remount extN filesystem in read-only mode, and test
failed due to "ro" mount option not found. We can add a touch to
trigger the action which aborts journal and ro-remounts the fs.
[eguan: update commit log and comments a bit]
Signed-off-by: yang xu <xuyang.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The lvm command can invoke the thin pool utilities as part of
managing a thin volume. It'll fail if the thin provisioning
utilities are not installed, so we need to check for its presence
before running a test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
With thin devices, it's possible to have a virtual device larger
than the physical device itself, and such situation can cause
problems to filesystems, once the filesystem 'believe' to have more
space than it actually has.
This can lead the filesystem to several weird behaviors. The one
tested here is filesystem lockup.
In case of XFS, it locks up when trying to writeback AIL metadata
back to the filesystem, but, once there is no physical space
available, XFS locks up and do not gracefuly handle this case.
Other filesystems usually are remounted as read-only, so they
already have this situation covered.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>