All of lore.kernel.org
 help / color / mirror / Atom feed
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/

      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.