From: Marek Behun <marek.behun@nic.cz>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: when does btrfs create sparse extents?
Date: Wed, 22 Apr 2020 22:58:51 +0200 [thread overview]
Message-ID: <20200422225851.3d031d88@nic.cz> (raw)
In-Reply-To: <CAJCQCtTEY347CwHGz3QKaBfxvPg0pTz_CF+OaiZNaCEGcnLfYA@mail.gmail.com>
On Wed, 22 Apr 2020 14:44:46 -0600
Chris Murphy <lists@colorremedies.com> wrote:
> e.g. from a 10m file created with truncate on two Btrfs file systems
>
> original holes format (default)
>
> item 6 key (257 EXTENT_DATA 0) itemoff 15768 itemsize 53
> generation 7412 type 1 (regular)
> extent data disk byte 0 nr 0
> extent data offset 0 nr 10485760 ram 10485760
> extent compression 0 (none)
>
> On a file system with no-holes feature set, this item simply doesn't
> exist. I think basically it works by inference. Both kinds of files
> have size in the INODE_ITEM, e.g.
>
> item 4 key (257 INODE_ITEM 0) itemoff 32245 itemsize 160
> generation 889509 transid 889509 size 10485760 nbytes 0
>
> Sparse extents are explicitly stated in the original format with disk
> byte 0 in an EXTENT_DATA item; whereas in the newer format, sparse
> extents exist whenever EXTENT_DATA items don't completely describe the
> file's size.
Ok this means that U-Boot currently gained support for the original
sparse extents.
I fear that current u-boot does not handle the new no-holes feature.
next prev parent reply other threads:[~2020-04-22 20:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 18:52 when does btrfs create sparse extents? Marek Behun
2020-04-22 20:26 ` Chris Murphy
2020-04-22 20:44 ` Marek Behun
2020-04-22 20:44 ` Chris Murphy
2020-04-22 20:58 ` Marek Behun [this message]
2020-04-22 21:05 ` Chris Murphy
2020-04-23 10:49 ` Filipe Manana
2020-04-23 11:42 ` Marek Behun
2020-04-23 11:51 ` Filipe Manana
2020-04-23 12:05 ` Marek Behun
2020-04-23 12:39 ` Filipe Manana
2020-04-23 19:50 ` Chris Murphy
2020-04-23 5:57 ` Andrei Borzenkov
2020-04-23 6:45 ` Marek Behun
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=20200422225851.3d031d88@nic.cz \
--to=marek.behun@nic.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.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.