All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Yugui <wangyugui@e16-tech.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "David C. Partridge" <david.partridge@perdrix.co.uk>,
	linux-btrfs@vger.kernel.org
Subject: Re: Problems with BTRFS formatted disk
Date: Mon, 20 Jun 2022 10:12:09 +0800	[thread overview]
Message-ID: <20220620101209.B0E9.409509F4@e16-tech.com> (raw)
In-Reply-To: <1f033574-9c56-8454-a4a2-7db57ffd0e01@gmx.com>

Hi,

> On 2022/6/20 09:01, Wang Yugui wrote:
> > Hi,
> >
> >> On 2022/6/20 04:06, David C. Partridge wrote:
> >>> Yes write caching was enabled - I suspect that the way it worked was that on power fail the super-caps held the data until power was restored.
> >>>
> >>> Sadly it wasn't restored for a few weeks by which time the super-caps had lost their charge.
> >>
> >> A little off-topic here, since I'm not familiar with how those hardware
> >> RAID controllers work.
> >>
> >> Yep, those cards should have (super) caps to handle power loss, but for
> >>    SCSI SYNC CACHE commands, they should "the device server ensure that
> >> the specified logical blocks have their most recent data values recorded
> >> in non-volatile cache and/or on the medium."
> >>
> >> Considering in a power loss event, the juice in those caps is definitely
> >> not enough to power those HDDs, it should at least have some
> >> non-volatile cache, like NAND, as backups.
> >>
> >> But from sites I can found, it only states the card has 1024MiB cache
> >> memory.
> >>
> >> Even with caps to keep the memory alive, it's still far from
> >> "non-volatile cache" required by SCSI spec.
> >>
> >> Or is this a common practice in hardware RAID controller world to use
> >> volatile cache and break the SCSI spec requirement?
> >
> >
> > "non-volatile cache"  require a battery(inside or separated) and
> > Backup Flash(inside or separated).
> 
> Then it comes the question, why there is need for battery if our
> non-volatile cache is NAND flash?
> Since NAND doesn't need power to keep its data.
> 
> My guess is, NAND flash is not fast enough so they have battery for RAM
> as the primary cache, and only when power loss happen, then use the
> battery to power the RAM so that we have enough time to dump the content
> of RAM into the backup flash?

Yes.

RAM/memory is fast than NAND. 
and NAND have the limit of total write bytes.


  reply	other threads:[~2022-06-20  2:12 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 18:55 Problems with BTRFS formatted disk David C. Partridge
2022-06-18 23:00 ` Qu Wenruo
2022-06-19  1:33   ` David C. Partridge
2022-06-19  2:01     ` Qu Wenruo
2022-06-19 10:29       ` David C. Partridge
2022-06-19 10:40         ` Qu Wenruo
2022-06-19 11:14           ` David C. Partridge
2022-06-19 11:51             ` Qu Wenruo
2022-06-19 12:53               ` David C. Partridge
2022-06-19 13:21                 ` Qu Wenruo
2022-06-19 13:26                 ` David C. Partridge
2022-06-19 13:30                   ` Qu Wenruo
2022-06-19 14:15                     ` David C. Partridge
2022-06-19 19:06                       ` Andrei Borzenkov
2022-06-19 20:06                         ` David C. Partridge
2022-06-20  0:38                           ` Qu Wenruo
2022-06-20  1:01                             ` Wang Yugui
2022-06-20  2:04                               ` Qu Wenruo
2022-06-20  2:12                                 ` Wang Yugui [this message]
2022-06-20  2:12                                   ` Qu Wenruo
2022-06-20  8:19                             ` David C. Partridge
2022-06-19 21:40                       ` Qu Wenruo
2022-06-20  8:17                         ` David C. Partridge
2022-06-19  1:37   ` David C. Partridge

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=20220620101209.B0E9.409509F4@e16-tech.com \
    --to=wangyugui@e16-tech.com \
    --cc=david.partridge@perdrix.co.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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.