xfstests 224: test aio hole-fill at 4g

Testcase from Giel de Nijs <[email protected]> on linux-ext4 list, ""Possible ext4 data corruption with large files and async I/O," on 29 Jan 2010

ext4 put byte offsets in a block offset u32 container in the endio struct, so 4g wrapped to 0 leading to data corruption when the unwritten extent did not get converted.

Quoted 8 lines · Eric Sandeen

Testcase from Giel de Nijs <[email protected]> on linux-ext4 list, ""Possible ext4 data corruption with large files and async I/O," on 29 Jan 2010

ext4 put byte offsets in a block offset u32 container in the endio struct, so 4g wrapped to 0 leading to data corruption when the unwritten extent did not get converted.

There's various type messups in the test program that make it fail for

me on a 32-bit machine. The patch below fixes it up, but it seems like we should rather add a variant of that code as aio_read/write commands to xfs_io instead of adding a new test program.

Index: xfstests-dev/src/aio-write.c
===================================================================

src/aio-write.c +5 -5

@@ -42,7 +42,7 @@ void usage(void)
 /*
  * Scale value by kilo, mega, or giga.
  */
-loff_t scale_by_kmg(long long value, char scale)
+long long scale_by_kmg(long long value, char scale)
 {
 switch (scale) {
 	case 'g':

@@ -69,7 +69,7 @@ switch (scale) {
 int main(int argc, char ** argv)
 {
 	char filename[PATH_MAX];
-	loff_t offset = 0;
+	long long offset = 0;
 	size_t length = 0;
 	int seed = 0xFF;
 	int queue_depth = 8;

@@ -95,12 +95,12 @@ int main(int argc, char ** argv)
 			seed = (int)strtol(optarg, &endp, 0);
 			break;
 		case 'o':
-			offset = strtol(optarg, &endp, 0);
-			offset = scale_by_kmg((long long)offset, *endp);
+			offset = strtoll(optarg, &endp, 0);
+			offset = scale_by_kmg(offset, *endp);
 			break;
 		case 'l':
 			length = strtol(optarg, &endp, 0);
-			length = scale_by_kmg((long long)length, *endp);
+			length = scale_by_kmg(length, *endp);
 			break;
 		case 'v':
 			verbose++;

Quoted 3 lines

me on a 32-bit machine. The patch below fixes it up, but it seems like we should rather add a variant of that code as aio_read/write commands to xfs_io instead of adding a new test program.

ok, that's probably better - again, though, it takes at least a release cycle before most folks can test it. But I guess that's not the end of the world.

Quoted 6 lines · Eric Sandeen

Quoted 3 lines

me on a 32-bit machine. The patch below fixes it up, but it seems like we should rather add a variant of that code as aio_read/write commands to xfs_io instead of adding a new test program.

ok, that's probably better - again, though, it takes at least a release cycle before most folks can test it. But I guess that's not the end of the world.

Stupid question --- who uses xfs_io besides xfstests? Any chance we could consider dropping in some version of xfs_io into xfstests, or actually moving it into xfstests from xfsprogs if xfstests is the exclusive user of that program? I've been trying to get more people to use xfstests, since it would be good if more companies and more projects were using it --- and one of the things that makes it hard is all of the dependencies that it has. If there was some way we could gradually make xfstests more self-contained, it would certainly be nice.

- Ted

These are the deps that I know xfstests has, to build and to run:

BuildRequires:  autoconf, libtool, xfsprogs-devel, e2fsprogs-devel
BuildRequires:  libacl-devel, libattr-devel, libaio-devel

Requires:       bash, xfsprogs, xfsdump, perl, acl, attr, bind-utils
Requires:       bc, indent, quota

which isn't so bad...

I'm not sure an xfsprogs dependency is so onerous; plenty has depended on e2fsprogs through the years and we've lived with that ;) But the lag time for xfsprogs to use released xfs_io functionality is a bit of a bummer.

But I guess I don't have a great answer for who else uses xfs_io:

Quoted 5 lines · Eric Sandeen

These are the deps that I know xfstests has, to build and to run:

BuildRequires:  autoconf, libtool, xfsprogs-devel, e2fsprogs-devel
BuildRequires:  libacl-devel, libattr-devel, libaio-devel

Quoted 4 lines

Requires:       bash, xfsprogs, xfsdump, perl, acl, attr, bind-utils
Requires:       bc, indent, quota

which isn't so bad...

Doesn't seem to bad. Indent is afaik only needed for the weird 122 test which doesn't apply to non-xfs filesystems.

Quoted 6 lines

I'm not sure an xfsprogs dependency is so onerous; plenty has depended on e2fsprogs through the years and we've lived with that ;) But the lag time for xfsprogs to use released xfs_io functionality is a bit of a bummer.

But I guess I don't have a great answer for who else uses xfs_io:

I use xfs_io in lots various local scripts. It's a really handly tool for exercising some of the more weird I/O related syscalls.

Testcase from Giel de Nijs <[email protected]> on linux-ext4 list, ""Possible ext4 data corruption with large files and async I/O," on 29 Jan 2010

ext4 put byte offsets in a block offset u32 container in the endio struct, so 4g wrapped to 0 leading to data corruption when the unwritten extent did not get converted.

Signed-off-by Eric Sandeen <[email protected]>

---

Quoted 9 lines · Eric Sandeen

Testcase from Giel de Nijs <[email protected]> on linux-ext4 list, ""Possible ext4 data corruption with large files and async I/O," on 29 Jan 2010

ext4 put byte offsets in a block offset u32 container in the endio struct, so 4g wrapped to 0 leading to data corruption when the unwritten extent did not get converted.

Quoted 3 lines

Signed-off-by Eric Sandeen <[email protected]>

---

Hey Eric

Just going through the list trying to clean it up. Is this patch still valid or does one of the other hole tests cover this?

Regards
--Rich

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs