2021-03-16 15:12:49

by Guochun Mao

Subject: [Patch v1 0/1] ubifs: only check replay with inode type to judge if inode linked

This patch make sure one file could be deleted completely when write and delete mixed
operations occur power-cut.

Guochun Mao (1):
ubifs: only check replay with inode type to judge if inode linked

fs/ubifs/replay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--
2.18.0

2021-03-16 15:12:49

by Guochun Mao

Subject: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked

From: Guochun Mao <[email protected]>

Conside the following case, it just write a big file into flash,
when complete writing, delete the file, and then power off promptly.
Next time power on, we'll get a replay list like:
...
LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
...
In the replay list, data nodes' deletion are 0, and the inode node's
deletion is 1. In current logic, the file's dentry will be removed,
but inode and the flash space it occupied will be reserved.
User will see that much free space been disappeared.

We only need to check the deletion value of the following inode type
node of the replay entry.

Signed-off-by: Guochun Mao <[email protected]>
---
fs/ubifs/replay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index 0f8a6a16421b..1929ec63a0cb 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
*/
list_for_each_entry_reverse(r, &c->replay_list, list) {
ubifs_assert(c, r->sqnum >= rino->sqnum);
- if (key_inum(c, &r->key) == key_inum(c, &rino->key))
+ if (key_inum(c, &r->key) == key_inum(c, &rino->key) &&
+ key_type(c, &r->key) == UBIFS_INO_KEY)
return r->deletion == 0;

}
--
2.18.0

2021-04-07 17:45:12

by Guochun Mao

Subject: Re: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked

Hi Richard,

Gentle ping.


On Tue, 2021-03-16 at 16:52 +0800, [email protected] wrote:
> From: Guochun Mao <[email protected]>
>
> Conside the following case, it just write a big file into flash,
> when complete writing, delete the file, and then power off promptly.
> Next time power on, we'll get a replay list like:
> ...
> LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
> LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
> LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
> ...
> In the replay list, data nodes' deletion are 0, and the inode node's
> deletion is 1. In current logic, the file's dentry will be removed,
> but inode and the flash space it occupied will be reserved.
> User will see that much free space been disappeared.
>
> We only need to check the deletion value of the following inode type
> node of the replay entry.
>
> Signed-off-by: Guochun Mao <[email protected]>
> ---
> fs/ubifs/replay.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 0f8a6a16421b..1929ec63a0cb 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
> */
> list_for_each_entry_reverse(r, &c->replay_list, list) {
> ubifs_assert(c, r->sqnum >= rino->sqnum);
> - if (key_inum(c, &r->key) == key_inum(c, &rino->key))
> + if (key_inum(c, &r->key) == key_inum(c, &rino->key) &&
> + key_type(c, &r->key) == UBIFS_INO_KEY)
> return r->deletion == 0;
>
> }

2021-04-07 22:07:59

by Richard Weinberger

Subject: Re: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked

On Tue, Mar 16, 2021 at 10:00 AM <[email protected]> wrote:
>
> From: Guochun Mao <[email protected]>
>
> Conside the following case, it just write a big file into flash,
> when complete writing, delete the file, and then power off promptly.
> Next time power on, we'll get a replay list like:
> ...
> LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80
> LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80
> LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80
> ...
> In the replay list, data nodes' deletion are 0, and the inode node's
> deletion is 1. In current logic, the file's dentry will be removed,
> but inode and the flash space it occupied will be reserved.
> User will see that much free space been disappeared.
>
> We only need to check the deletion value of the following inode type
> node of the replay entry.
>
> Signed-off-by: Guochun Mao <[email protected]>
> ---
> fs/ubifs/replay.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
> index 0f8a6a16421b..1929ec63a0cb 100644
> --- a/fs/ubifs/replay.c
> +++ b/fs/ubifs/replay.c
> @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino)
> */
> list_for_each_entry_reverse(r, &c->replay_list, list) {
> ubifs_assert(c, r->sqnum >= rino->sqnum);
> - if (key_inum(c, &r->key) == key_inum(c, &rino->key))
> + if (key_inum(c, &r->key) == key_inum(c, &rino->key) &&
> + key_type(c, &r->key) == UBIFS_INO_KEY)

This change makes sense. Thanks a lot for hunting this down.
It will be part of the merge window.

--
Thanks,
//richard