From: Richard Weinberger <richard@nod.at>
To: chengzhihao1 <chengzhihao1@huawei.com>
Cc: Ryder Wang <rydercoding@hotmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: ubifs: why ubifs doesn't support 2 copied of super blocks for better fs reliability
Date: Sat, 29 Jun 2024 15:56:29 +0200 (CEST) [thread overview]
Message-ID: <84530892.9887.1719669389649.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <f9c0f1f3-5fbf-c86d-4056-b75ee368df76@huawei.com>
----- Ursprüngliche Mail -----
> Von: "chengzhihao1" <chengzhihao1@huawei.com>
> An: "Ryder Wang" <rydercoding@hotmail.com>, "linux-mtd" <linux-mtd@lists.infradead.org>, "richard" <richard@nod.at>
> Gesendet: Samstag, 29. Juni 2024 13:22:34
> Betreff: Re: ubifs: why ubifs doesn't support 2 copied of super blocks for better fs reliability
> 在 2024/6/28 10:28, Ryder Wang 写道:
>> Hello,
>>
>> It looks ubifs has only 1 super block. Super block may be corrupted by power-cut
No. The super block must not get corrupted by a sudden loss of power.
If you're facing this, something else in your storage stack is broken.
>> while NAND erasing or writing, ECC error and etc. When super block is
>> corrupted, ubifs mount will always fail.
>>
>
> Have you met the problem caused by corrupted superblock? I only saw once
> in our product, in which there ware many problem eraseblocks in the flash.
>
>> I am asking why ubifs doesn't support 2 copied of super blocks for better fs
>> reliability? As we know, both uibfs master block and ubi volume table have 2
>> copies, so they are very stronger. Is there any dev plan to support it on super
>> block?
>
> I have no ideas about this question either after looking through the
> history and whitepaper[1]. The superblock is updated in a very low
> frequency(eg. auto-resize), and it is updated by atomic changing. So I
> guess that corrupted superblock is hardly generated from the view of
> UBIFS layer. However, the UBI will do wear-leveing, which could
> atomically exchange two LEBs(may contain superblock), then the updating
> frequency of superblock could be increased. The final probability of
> corrupted superblock is hard to say. So, I'm not sure it's a very
> valuable thing to maintain two superblocks in UBIFS, afterall, it will
> change disk structure.
UBIFS relies on working flash memory, so having multiple copies makes no sense
since one of UBIFS' goals is also being space efficient.
There is one exception: it has two master LEBs. For historic reasons,
it needs to exchange theirs contents automatically, at the time when UBIFS
was young, UBI had no atomic-leb-change feature.
Thanks,
//richard
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2024-06-29 13:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 5:59 ubi: some invalid code in the function scan_peb Ryder Wang
2023-10-18 6:31 ` Zhihao Cheng
2023-10-18 7:28 ` Ryder Wang
2023-10-18 7:42 ` Zhihao Cheng
[not found] ` <MEYP282MB3164987D45E3CFC61B3E7CECBFD02@MEYP282MB3164.AUSP282.PROD.OUTLOOK.COM>
2024-06-29 11:22 ` ubifs: why ubifs doesn't support 2 copied of super blocks for better fs reliability Zhihao Cheng
2024-06-29 13:56 ` Richard Weinberger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84530892.9887.1719669389649.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=chengzhihao1@huawei.com \
--cc=linux-mtd@lists.infradead.org \
--cc=rydercoding@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.