On Mon, Feb 25, 2019 at 3:33 AM zhengbin (A) <zhengbin13@xxxxxxxxxx> wrote: > > Thanks for your reply. > > > I don't quite like the idea of "forking" random tests from 'generic' to > > 'readonly'. The biggest benefit of adding new fs support to fstests is > > that it shares most of the 'generic' tests and gets good test coverage. > > But forking a very small subset of generic tests not only defeats the > > benefit but also adding extra maintain burden > --->I agree that, but if we want to add readonly filesystem support in fstests, > maybe it is the best way?I didn't find a better way > > On 2019/2/24 23:39, Eryu Guan wrote: > > [Sorry for being so long to review this squashfs support.] > > > > On Tue, Jan 22, 2019 at 11:24:02AM +0800, zhengbin wrote: > >> This patch add squashfs support in xfstests-dev. Add two directories > >> in tests directory, readonly can also be used for other readonly > >> filesystem, squashfs is just used for squashfs filesystem. > >> tests/readonly/001 mount test > >> tests/readonly/002--010 metadata test > >> tests/readonly/011--018 data test > >> tests/readonly/019--021 xattr test > >> tests/squashfs/001--005 mksquashfs options test > > > > I don't quite like the idea of "forking" random tests from 'generic' to > > 'readonly'. The biggest benefit of adding new fs support to fstests is > > that it shares most of the 'generic' tests and gets good test coverage. > > But forking a very small subset of generic tests not only defeats the > > benefit but also adding extra maintain burden. > > > > But the problem is that squashfs is a readonly filesystem and sharing > > the existing generic tests is not easy. (Actually I've been looking at > > this series several times, but couldn't come out with a good solution.) > > Because fstests harness assumes the filesystem being tested is writable > > by default, various _require rules also write/create files to check if a > > functionality is supported by the underlying filesystem. This leads me > > to wonder if fstests is suitable for such readonly filesystems? > > > > I'm glad to hear what do others think, any comments are welcomed! > > Maybe the problem is not the forking of readonly tests, but the fact that these tests cannot be shared as is with other filesystems. I know I once fixed a bug or two when ext4 was mounted on a readonly blockdev (i.e. with ext4 snapshots). readonly tests could be meaningful to other filesystems if constructed as: _require_scratch_readonly_blkdev _scratch_blkdev_setrw _scratch_mkfs _scratch_mount setup() _scratch_umount _scratch_blkdev_setro _scratch_mount_readonly_blkdev test() Of course for squashfs, _scratch_mount will be "mounting" a scratch tmpdir and only _scratch_mount_readonly_blkdev will really be mounting a squashfs. Thanks, Amir.
