[Top] [All Lists]

Re: [PATCH v2 2/2] xfstests: introduce 280 for SEEK_DATA/SEEK_HOLE copy

To: jeff.liu@xxxxxxxxxx
Subject: Re: [PATCH v2 2/2] xfstests: introduce 280 for SEEK_DATA/SEEK_HOLE copy check
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Tue, 07 Feb 2012 08:17:09 -0600
Cc: xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>
In-reply-to: <4F30D563.8030807@xxxxxxxxxx>
References: <4F2FE410.2040508@xxxxxxxxxx> <4F305472.8070509@xxxxxxx> <4F30D563.8030807@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 02/07/12 01:40, Jeff Liu wrote:
Hi Mark,

On 02/07/2012 06:30 AM, Mark Tinguely wrote:

On 02/06/12 08:30, Jeff Liu wrote:
Introduce 280 for SEEK_DATA/SEEK_HOLE copy check.

Signed-off-by: Jie Liu<jeff.liu@xxxxxxxxxx>


diff --git a/src/seek_copy_tester.c b/src/seek_copy_tester.c
new file mode 100644
index 0000000..ddf683f
--- /dev/null
+++ b/src/seek_copy_tester.c

+static size_t
+full_write(int fd, const void *buf, size_t count)
+    size_t total = 0;
+    const char *ptr = (const char *) buf;
+    while (count>   0) {
+        ssize_t n = write(fd, ptr, count);
+        if (n<   0) {
+            if (errno == EINTR)
+                continue;

Wouldn't you want to stop the write loop if interrupted?

As this routine was called "full_write" which means it is expect to write as 
much as it can.
So I would keep retrying if the process was interrupted by EINTR.
Would you please give some opinions whether this approach is not suitable in 
this circumstance?

Maybe I was thinking wrong. I was thinking if someone had killed the test and the write was interrupted by the signal, then you would give up the write loop.


<Prev in Thread] Current Thread [Next in Thread>