All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David C. Partridge" <david.partridge@perdrix.co.uk>
To: "'Qu Wenruo'" <quwenruo.btrfs@gmx.com>, <linux-btrfs@vger.kernel.org>
Subject: RE: Problems with BTRFS formatted disk
Date: Mon, 20 Jun 2022 09:19:36 +0100	[thread overview]
Message-ID: <009701d8847e$7b98d930$72ca8b90$@perdrix.co.uk> (raw)
In-Reply-To: <5d892115-c132-b2ea-7651-9cb94f76ee6b@gmx.com>

I don't know ... The Super-Caps only power the cache memory ...

-----Original Message-----
From: Qu Wenruo <quwenruo.btrfs@gmx.com> 
Sent: 20 June 2022 01:38
To: David C. Partridge <david.partridge@perdrix.co.uk>; linux-btrfs@vger.kernel.org
Subject: Re: Problems with BTRFS formatted disk



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?

Thanks,
Qu
>
> I've reconfigured to use write through.
>
>
> -----Original Message-----
> From: Andrei Borzenkov <arvidjaar@gmail.com>
> Sent: 19 June 2022 20:06
> To: David C. Partridge <david.partridge@perdrix.co.uk>; 'Qu Wenruo' <quwenruo.btrfs@gmx.com>; linux-btrfs@vger.kernel.org
> Subject: Re: Problems with BTRFS formatted disk
>
> On 19.06.2022 17:15, David C. Partridge wrote:
>> I can't "grab what I can" as I don't have enough TB to copy the data I want to save ☹
>>
>> Does it make any sense to try:
>>
>>   mount -o remount,rw /mnt
>>   btrfs subvolume delete /mnt/@
>>   btrfs subvolume delete /mnt/@_daily.20220525_00:11:01
>>   btrfs subvolume delete /mnt/@_daily.20220526_00:11:01
>>   btrfs subvolume delete /mnt/@_hourly.20220526_06:00:01
>>   btrfs subvolume delete /mnt/@_hourly.20220526_09:00:01
>>   btrfs subvolume delete /mnt/@_hourly.20220526_12:00:01
>>
>>   mv /mnt/@_daily.20220524_00:11:01 /mnt/@
>>
>> or is that doomed to total failure?
>>
>> The disks behind the raid card are all Western Digital WD4001FYYG SAS drives
>>
>
> Is write caching enabled for these disks? I know that it is default for
> some RAID cards (at least, for some profiles).
>
> For disks behind RAID controller write caching is normally managed by
> RAID controller itself.
>


  parent reply	other threads:[~2022-06-20  8:19 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
2022-06-20  2:12                                   ` Qu Wenruo
2022-06-20  8:19                             ` David C. Partridge [this message]
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='009701d8847e$7b98d930$72ca8b90$@perdrix.co.uk' \
    --to=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.