From: John Dorminy <jdorminy@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Bob Liu <bob.liu@oracle.com>,
device-mapper development <dm-devel@redhat.com>,
Damien LeMoal <damien.lemoal@wdc.com>,
Mike Snitzer <snitzer@redhat.com>
Subject: Re: [PATCH 3/4] dm-zoned: V2 metadata handling
Date: Thu, 2 Apr 2020 11:52:42 -0400 [thread overview]
Message-ID: <CAMeeMh9JBuOuOi2s0VB6K1KXExUv-kyP2OavRXE==tHJAXbMFg@mail.gmail.com> (raw)
In-Reply-To: <bbebc0d7-2d53-8412-81c2-d36842fc25e9@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1368 bytes --]
That does make sense. May I request, then, using UUID_SIZE instead of 16?
Perhaps with a compile-time assertion that UUID_SIZE has not change from 16?
On Thu, Apr 2, 2020 at 11:10 AM Hannes Reinecke <hare@suse.de> wrote:
> On 4/2/20 4:53 PM, John Dorminy wrote:
> > I'm worried about hardcoding uuid members as u8[16].
> >
> > May I ask why you're not using uuid_t to define it in the on-disk
> > structure? It would save the casting of the uuid members to (uuid_t *)
> > every time you use a uuid.h function.
> >
> > Possibly it is customary to use only raw datatypes on disk rather than
> > opaque types like uuid_t, I'm not sure. But in that case, perhaps using
> > the named constant UUID_SIZE instead of 16 would make the meaning
> clearer?
> >
> I prefer to use absolute types (like __u8) when describing the on-disk
> format.
> When using opaque types like uuid_t there always is the risk that the
> internal representation will change, leading to an involuntary change of
> the on-disk format structure and subsequent compability issues.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Teamlead Storage & Networking
> hare@suse.de +49 911 74053 688
> SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
> HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
>
>
[-- Attachment #1.2: Type: text/html, Size: 1817 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2020-04-02 15:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 7:14 [PATCH RFC 0/4] dm-zoned: Metadata V2 Hannes Reinecke
2020-03-27 7:14 ` [PATCH 1/4] dm-zoned: store zone id within the zone structure Hannes Reinecke
2020-03-31 0:57 ` Damien Le Moal
2020-03-31 8:54 ` Hannes Reinecke
2020-03-27 7:14 ` [PATCH 2/4] dm-zoned: use array for superblock zones Hannes Reinecke
2020-03-31 0:51 ` Damien Le Moal
2020-03-31 9:10 ` Bob Liu
2020-03-27 7:14 ` [PATCH 3/4] dm-zoned: V2 metadata handling Hannes Reinecke
2020-03-31 0:54 ` Damien Le Moal
2020-03-31 9:11 ` Bob Liu
2020-04-02 14:53 ` John Dorminy
2020-04-02 15:09 ` Hannes Reinecke
2020-04-02 15:52 ` John Dorminy [this message]
2020-04-02 20:01 ` John Dorminy
2020-04-03 5:47 ` Damien Le Moal
2020-03-27 7:14 ` [PATCH 4/4] dm-zoned: allow for device size smaller than the capacity Hannes Reinecke
2020-03-31 0:49 ` Damien Le Moal
2020-03-31 8:53 ` Hannes Reinecke
2020-04-02 2:45 ` Damien Le Moal
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='CAMeeMh9JBuOuOi2s0VB6K1KXExUv-kyP2OavRXE==tHJAXbMFg@mail.gmail.com' \
--to=jdorminy@redhat.com \
--cc=bob.liu@oracle.com \
--cc=damien.lemoal@wdc.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=snitzer@redhat.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.