[
https://issues.apache.org/jira/browse/HDDS-10770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sammi Chen updated HDDS-10770:
------------------------------
Description:
Case1
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data
3. client1 close fileA
4. client2 close fileA
Expected result:
fileA with block2 in keyTable // final fileA data is block2
fileA with block1 in deletedKeyTable // block1 is deleted
Case2
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data, call hsync, close fileA
3. client1 close fileA
Expected result:
fileA with block1 in keyTable // final fileA data is block1
fileA with block2 in deletedKeyTable // block2 is deleted
Case3:
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data, call hsync
3. client1 close fileA
4. client2 close fileA
Expected result:
fileA with block1 in keyTable // final fileA data is block1
client2 close fileA should fail
fileA with block2 in deletedKeyTable // block2 is deleted
Case4:
1. client1 open fileA with block1, write some data, call hsync
2. client2 open fileA with block2, write some data, call hsync
3. client1 close fileA
4. client2 close fileA
Expected result:
client1 close call will fail while client2 close will succeed.
final fileA data is block2, block1 will be delted.
!screenshot-1.png!
The overall rule is
a. the later commit overwrites early commit
b. avoid mutual overwrites. Once a file is overwritten, it cannot later
overwritten others again.
To support this, when a hsynced file is overwritten, it will have "overwritten"
metadata as a flag. All following allocate block, further hsync or commit of
this file will fail.
was:
Case1
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data
3. client1 close fileA
4. client2 close fileA
Expected result:
fileA with block2 in keyTable // final fileA data is block2
fileA with block1 in deletedKeyTable // block1 is deleted
Case2
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data, call hsync, close fileA
3. client1 close fileA
Expected result:
fileA with block1 in keyTable // final fileA data is block1
fileA with block2 in deletedKeyTable // block2 is deleted
Case3:
1. client1 open fileA with block1, write some data
2. client2 open fileA with block2, write some data, call hsync
3. client1 close fileA
4. client2 close fileA
Expected result:
fileA with block1 in keyTable // final fileA data is block1
client2 close fileA should fail
fileA with block2 in deletedKeyTable // block2 is deleted
Case4:
1. client1 open fileA with block1, write some data, call hsync
2. client2 open fileA with block2, write some data, call hsync
3. client1 close fileA
4. client2 close fileA
Expected result:
client1 close call will fail while client2 close will succeed.
final fileA data is block2, block1 will be delted.
Key(KeyTable) + Key(OpenKeyTable) New key Commit Behavior Comments
no hsync no openKey normal commit allow Key in
KeyTable deleted
no hsync no openKey hsync commit allow Key in
KeyTable deleted
hsync hsync normal commit allow Key in
KeyTable deleted, Key in OpenKeyTable mark as "overwritten", allocate block,
further hsync or commit will fail
hsync-clientID1 hsync-clientID1 hsycn-clientID1 commit allow
hsync-clientID1 hsync-clientID1 hsync-clientID2 commit allow Key
in KeyTable deleted, Key in OpenKeyTable mark as "overwritten", allocate block,
further hysnc or commit will fail
The overall rule is
a. the later commit overwrites early commit
b. avoid mutual overwrites. Once a file is overwritten, it cannot later
overwritten others again.
To support this, when a hsynced file is overwritten, it will have "overwritten"
metadata as a flag. All following allocate block, further hsync or commit of
this file will fail.
> [Hsync] Allow overwrite hsynced file
> ------------------------------------
>
> Key: HDDS-10770
> URL: https://issues.apache.org/jira/browse/HDDS-10770
> Project: Apache Ozone
> Issue Type: Improvement
> Reporter: Sammi Chen
> Assignee: Sammi Chen
> Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> Case1
> 1. client1 open fileA with block1, write some data
> 2. client2 open fileA with block2, write some data
> 3. client1 close fileA
> 4. client2 close fileA
> Expected result:
> fileA with block2 in keyTable // final fileA data is block2
> fileA with block1 in deletedKeyTable // block1 is deleted
> Case2
> 1. client1 open fileA with block1, write some data
> 2. client2 open fileA with block2, write some data, call hsync, close fileA
> 3. client1 close fileA
> Expected result:
> fileA with block1 in keyTable // final fileA data is block1
> fileA with block2 in deletedKeyTable // block2 is deleted
> Case3:
> 1. client1 open fileA with block1, write some data
> 2. client2 open fileA with block2, write some data, call hsync
> 3. client1 close fileA
> 4. client2 close fileA
> Expected result:
> fileA with block1 in keyTable // final fileA data is block1
> client2 close fileA should fail
> fileA with block2 in deletedKeyTable // block2 is deleted
> Case4:
> 1. client1 open fileA with block1, write some data, call hsync
> 2. client2 open fileA with block2, write some data, call hsync
> 3. client1 close fileA
> 4. client2 close fileA
> Expected result:
> client1 close call will fail while client2 close will succeed.
> final fileA data is block2, block1 will be delted.
> !screenshot-1.png!
> The overall rule is
> a. the later commit overwrites early commit
> b. avoid mutual overwrites. Once a file is overwritten, it cannot later
> overwritten others again.
> To support this, when a hsynced file is overwritten, it will have
> "overwritten" metadata as a flag. All following allocate block, further hsync
> or commit of this file will fail.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
