From: NeilBrown <neilb@suse.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid <linux-raid@vger.kernel.org>,
jes.sorensen@redhat.com,
Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
Dave Jiang <dave.jiang@intel.com>
Subject: Re: [RFC PATCH 1/3] md/isrt: base infrastructure and metadata loading
Date: Thu, 24 Apr 2014 18:02:52 +1000 [thread overview]
Message-ID: <20140424180252.490434c6@notabene.brown> (raw)
In-Reply-To: <CAA9_cmcfGvBVTbxbBKBsgsnkyAux_VyKcM3V6v+tY5quQTotkQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
On Thu, 24 Apr 2014 00:38:01 -0700 Dan Williams <dan.j.williams@intel.com>
wrote:
> On Thu, Apr 24, 2014 at 12:24 AM, NeilBrown <neilb@suse.de> wrote:
> > On Wed, 23 Apr 2014 23:18:49 -0700 Dan Williams <dan.j.williams@intel.com>
> > wrote:
> >
> >> Initial md / block boilerplate for the Intel (R) Smart Response
> >> Technology compatibility driver. Supports reading the packed metadata
> >> and parsing it into a cache lookup tree.
> >>
> >> Cc: Dave Jiang <dave.jiang@intel.com>
> >> Cc: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
> >> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> >
> > It would really help in reviewing this to have a glossary.
> >
> > There are frames and segments and sectors and pages.
> >
> > I hope sectors are 512 bytes and pages are PAGE_SIZE, which may or may not be
> > 4096.
> >
> > And there are 16 sectors per frame, so I guess space is allocated in the
> > cache in 8K aligned frames ??
> >
> > There are 64 segments per page so if pages did happen to be 4096 bytes, that
> > makes 64 bytes per segment. What are they?
> >
> > There is a list somewhere of 32byte frame descriptors which is read into a
> > single vmalloced region (why? you keep page pointers, so why not read it into
> > separate pages?)
> > How is this organised? I might be able to work that out from the code, but
> > I'd rather not.
> >
> > Please don't make me guess, I'm not good at it.
> >
> > I guess it didn't help that diff out the header after the code. I got bored
> > before I got there and didn't read all to words, so maybe some answers are in
> > there. They don't really stand out though.
>
> No, they don't. Let me throw together a proper cheat sheet.
Thanks.
>
> > You've chosen '8' for the 'level' number.
>
> Hmm, ok. I use -12 in the mdadm bits, I neglected to go back and fix
> up the kernel.
>
> > As this is an array which doesn't have redundancy, I'd rather a number <= 0.
> > I think there are places where I assume >=1 has redundancy and understands
> > spares etc.
> >
> > Should conf->count be a kref??? Just a thought, not a requirement.
>
> Doesn't kref == 0 imply object destroyed? It's a count of pending
> metadata events.
kref means that in a kobject. Elsewhere it means whatever you want.
mpb_read_endio would kref_put(&conf->ref, release)
where release would get the conf and wake_up(&conf->eventq);
It probably isn't a big win..
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2014-04-24 8:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 6:18 [RFC PATCH 0/3] Base compatibility support for Intel(R) Smart Response Technology Dan Williams
2014-04-24 6:18 ` [RFC PATCH 1/3] md/isrt: base infrastructure and metadata loading Dan Williams
2014-04-24 7:24 ` NeilBrown
2014-04-24 7:38 ` Dan Williams
2014-04-24 8:02 ` NeilBrown [this message]
2014-04-24 17:33 ` Dan Williams
2014-04-24 23:44 ` NeilBrown
2014-04-24 23:55 ` Dan Williams
2014-04-24 6:18 ` [RFC PATCH 2/3] md/isrt: read support Dan Williams
2014-04-24 6:19 ` [RFC PATCH 3/3] md/isrt: write support Dan Williams
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=20140424180252.490434c6@notabene.brown \
--to=neilb@suse.de \
--cc=artur.paszkiewicz@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=jes.sorensen@redhat.com \
--cc=linux-raid@vger.kernel.org \
/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.