All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Martin Wilck <mwilck@arcor.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: DDF: regression caused by 273989b9 / ce45c819
Date: Wed, 7 Aug 2013 17:09:55 +1000	[thread overview]
Message-ID: <20130807170955.7333a5a6@notabene.brown> (raw)
In-Reply-To: <52013D0B.8060404@arcor.de>

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Tue, 06 Aug 2013 20:14:35 +0200 Martin Wilck <mwilck@arcor.de> wrote:

> Hi Neil,
> 
> these patches break the unit test 10ddf-geometry. I saw the regression
> with both patches applied. The problem occurs when subarrays are
> deleted. With these patches in place, sync_metadata() will not overwrite
> deleted conf records on disk, but lseek() over them instead. When the
> meta data is read back, this will cause errors.
> 
> I would like to ask you to play safe here and revert these patches. It
> might be possible to fix the --kill-subarray problem, but there are
> other possible scenarios where the number of valid conf records on a
> disk decreases - I don't think we have a reliable way to check whether
> it is safe to skip over empty entries. We must also be prepared for
> other DDF implementations to read our meta data, so we must refrain from
> putting any writing anything that might be confusing.
> 
> Regards
> Martin

Yes, you are right.  That wasn't such a good idea, thanks.

I've changed it to allocate a large buffer (which is done for 'read' - and we
use the same buffer), fill that in and write.  That is a lot faster than lots
of individual writes, due to the fact that the fd is O_DIRECT.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

      reply	other threads:[~2013-08-07  7:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-06 18:14 DDF: regression caused by 273989b9 / ce45c819 Martin Wilck
2013-08-07  7:09 ` NeilBrown [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=20130807170955.7333a5a6@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=mwilck@arcor.de \
    /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.