From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Toomas Soome <tsoome@me.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH 3/5] zfs com.delphix:hole_birth feature support
Date: Sun, 3 May 2015 18:15:05 +0300 [thread overview]
Message-ID: <20150503181505.238adeed@opensuse.site> (raw)
In-Reply-To: <2CB0E10D-6AEF-4345-A3B4-5B62167E9987@me.com>
В Sun, 19 Apr 2015 17:57:04 +0300
Toomas Soome <tsoome@me.com> пишет:
>
> > On 19.04.2015, at 17:51, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >
> > В Sun, 19 Apr 2015 17:40:16 +0300
> > Toomas Soome <tsoome@me.com> пишет:
> >
> >>
> >> the features in openzfs have different effects, some affect only writes and are therefore read only compatible - such feature does not need any changes for reads, this feature is not read only compatible and therefore, once this feature is enabled, reader code must be changed accordingly.
> >>
> >> so, what they did with hole_birth was they started to insert block birth timestamps for blocks being released to make it possible to track such blocks while doing zfs send (when block has birth time, you know its place on timeline of snapshots). as old reader code was relying on blk_birth == 0 to detect an hole, after hole_birth is enabled, hole blk_birth is not 0 any more, so the solution is to check if DVA pointers are zero instead. and thats exactly what its about.
> >
> > And if hole_birth is *not* enabled on a filesystem we are reading?
> > Should not old code be used in this case?
>
>
> not really, as for holes, DVA pointers are zero anyhow. I guess the original implementation used blk_birth to save extra compare - so the new read code is compatible with old data.
Committed with explanatory text for non-insiders.
>
>
> >
> >>
> >> reference:
> >> https://github.com/illumos/illumos-gate/commit/43466aae47bfcd2ad9bf501faec8e75c08095e4f
> >>
> >>
> >>
> >>> On 19.04.2015, at 17:11, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >>>
> >>> В Thu, 16 Apr 2015 08:22:08 +0300
> >>> Toomas Soome <tsoome@me.com> пишет:
> >>>
> >>> This really needs better explanation. Otherwise this looks like either
> >>> old code was broken to start with and it is a bug fix or new code needs
> >>> some conditionals on new feature.
> >>>
> >>>>
> >>>> ---
> >>>> grub-core/fs/zfs/zfs.c | 6 ++++--
> >>>> include/grub/zfs/spa.h | 4 +++-
> >>>> 2 files changed, 7 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
> >>>> index 2689986..a731c3d 100644
> >>>> --- a/grub-core/fs/zfs/zfs.c
> >>>> +++ b/grub-core/fs/zfs/zfs.c
> >>>> @@ -280,7 +280,9 @@ grub_crypto_cipher_handle_t (*grub_zfs_load_key) (const struct grub_zfs_key *key
> >>>> */
> >>>> #define MAX_SUPPORTED_FEATURE_STRLEN 50
> >>>> static const char *spa_feature_names[] = {
> >>>> - "org.illumos:lz4_compress",NULL
> >>>> + "org.illumos:lz4_compress",
> >>>> + "com.delphix:hole_birth",
> >>>> + NULL
> >>>> };
> >>>>
> >>>> static int
> >>>> @@ -1751,7 +1753,7 @@ zio_read_gang (blkptr_t * bp, grub_zfs_endian_t endian, dva_t * dva, void *buf,
> >>>>
> >>>> for (i = 0; i < SPA_GBH_NBLKPTRS; i++)
> >>>> {
> >>>> - if (zio_gb->zg_blkptr[i].blk_birth == 0)
> >>>> + if (BP_IS_HOLE(&zio_gb->zg_blkptr[i]))
> >>>> continue;
> >>>>
> >>>> err = zio_read_data (&zio_gb->zg_blkptr[i], endian, buf, data);
> >>>> diff --git a/include/grub/zfs/spa.h b/include/grub/zfs/spa.h
> >>>> index 7edb8ab..df43b6b 100644
> >>>> --- a/include/grub/zfs/spa.h
> >>>> +++ b/include/grub/zfs/spa.h
> >>>> @@ -279,7 +279,9 @@ typedef struct blkptr {
> >>>>
> >>>> #define BP_IDENTITY(bp) (&(bp)->blk_dva[0])
> >>>> #define BP_IS_GANG(bp) DVA_GET_GANG(BP_IDENTITY(bp))
> >>>> -#define BP_IS_HOLE(bp) ((bp)->blk_birth == 0)
> >>>> +#define DVA_IS_EMPTY(dva) ((dva)->dva_word[0] == 0ULL && \
> >>>> + (dva)->dva_word[1] == 0ULL)
> >>>> +#define BP_IS_HOLE(bp) DVA_IS_EMPTY(BP_IDENTITY(bp))
> >>>>
> >>>> /* BP_IS_RAIDZ(bp) assumes no block compression */
> >>>> #define BP_IS_RAIDZ(bp) (DVA_GET_ASIZE(&(bp)->blk_dva[0]) > \
> >>>
> >>>
> >>> _______________________________________________
> >>> Grub-devel mailing list
> >>> Grub-devel@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/grub-devel
> >>
> >>
> >> _______________________________________________
> >> Grub-devel mailing list
> >> Grub-devel@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
>
next prev parent reply other threads:[~2015-05-03 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 5:22 [PATCH 3/5] zfs com.delphix:hole_birth feature support Toomas Soome
2015-04-19 14:11 ` Andrei Borzenkov
2015-04-19 14:40 ` Toomas Soome
2015-04-19 14:51 ` Andrei Borzenkov
2015-04-19 14:57 ` Toomas Soome
2015-05-03 15:15 ` Andrei Borzenkov [this message]
2015-05-07 9:22 ` Vladimir 'φ-coder/phcoder' Serbinenko
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=20150503181505.238adeed@opensuse.site \
--to=arvidjaar@gmail.com \
--cc=grub-devel@gnu.org \
--cc=tsoome@me.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.