HDDS-5732 datanode duplicate write when concurrent write

[cchenax]

What changes were proposed in this pull request?

when concurrent write,for example,the chunkinfo{offset is 8192000,chunk size is 4096000} write in chunkfile,but the chunkinfo{offset is 4096000,chunk size is 4096000} is not write in chunkfile,so when this chunkinfo write in chunkfile will print warning log datanode duplicate write,but this chunkinfo was not wrote before.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-5732

How was this patch tested?

ci

[kaijchen]

Can we use chunkFile.length() instead of seek and read?

[cchenax]

chunkfile.length depend on the offset

[kaijchen]

If my understanding is correct, you are trying to solve sparse file "overwrite" problem.

But this code still prints true.

    public static void main(String[] args) {
        File f = new File("/tmp/hello");
        try (FileOutputStream out = new FileOutputStream(f);
             FileInputStream in = new FileInputStream(f)) {

            out.getChannel().position(8 << 10); // 8KB
            out.write("hello, world".getBytes(StandardCharsets.UTF_8));

            System.out.println(f.length()); // prints 8204 (= 8192 + 12)

            in.getChannel().position(4 << 10); // 4KB
            if (in.read() == -1) { // read() = 0
                System.out.println(false);
            } else {
                System.out.println(true); // prints true
            }
        } catch (IOException e) {
            System.out.println(e);
        }
    }

[cchenax]

Ozone write the contents of the buffer from the current position to the limit

[kaijchen]

Can you give an example of inputs, when your code and the original code will return different results?

[bshashikant]

Thanks @cchenax for the patch. To check the overwrite flag , seek and trying to read something may not be a viable option. With sparse files, read should return 0's not EOF. Do we still see concurrent writes for the same block?

[bshashikant]

@cchenax , any update?

[ChenSammi]

Hi @bshashikant , the issue is a false alert. I will close the PR.