From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: QiZhou <atmgnd@outlook.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [PATCH][Ext4Pkg] unwritten extent suuport
Date: Wed, 27 Oct 2021 22:34:20 +0100 [thread overview]
Message-ID: <CAKbZUD0AJ9HddRsHVPdzPvk6kcDK72Pwm5ACzxj=6OzQaMi7xw@mail.gmail.com> (raw)
In-Reply-To: <SYZP282MB325258630A3298D67BD664D8C9859@SYZP282MB3252.AUSP282.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 6014 bytes --]
Hi Qi,
If you didn't use the Linux kernel (nor the documentation) as a reference,
can you please tell me what you've used? I'm asking because there's at
least a line that's suspiciously similar to Linux's code:
#define EXTENT_INIT_MAX_LEN (1UL << 15)
the UL looks redundant to me, since there's no need for it.
Also, I prefer that you fix the typos yourself and format the patch
correctly, including the code.
On Wed, Oct 27, 2021 at 4:45 PM QiZhou <atmgnd@outlook.com> wrote:
> 1. I am not familiar with freebsd, and don know if freebsd get the same
> issue,
> But I do found the freebsd has some code snippets related to unwritten
> extent,
> see:
> https://github.com/freebsd/freebsd-src/blob/b3f46656393f5c8a6e8305afeb5e8c3638025c26/sys/fs/ext2fs/ext2_extents.h#L37
>
> https://github.com/freebsd/freebsd-src/blob/b3f46656393f5c8a6e8305afeb5e8c3638025c26/sys/fs/ext2fs/ext2_extents.c#L1347
> Is Ext4 is freebsd's default/major file system ?
>
> 2. I did't look at linux kernel(ext4) berfor send this patch, I cant
> found any offcial document, so I refer to linux source as a standand
> when send this patch
>
> 3. Yes, unwritten extents are wild used, usally when a file cotains many
> zeros, or mark file holes(fallocate, qemu-img...)
> You can generate a file contains a lot of unwritten extents by qemu, for
> example:
> qemu-img convert -f raw -O qcow2 win10.img win10.qcow2
> # win10.img's size: 10G
> But for files do not have any continuous zeros, like compressed files,
> then there will be no any unwritten extents
> unwritten extents are usally seen in very large files
>
> 4. You can fix the typos, My English is not so good
>
> On Oct 27 2021, at 10:56 pm, Pedro Falcato <pedro.falcato@gmail.com>
> wrote:
>
> > Hi,
> >
> > The patch looks OK despite the typos and lack of proper formatting on
> > the commit message.
> >
> > But honestly, I don't know if this patch is even mergeable considering
> > you looked at the Linux kernel's source code for this. The patch was
> > already trivial enough
> > if you looked at the documentation and the FreeBSD driver (as I had
> > done in the past but never got to fixing this considering I don't even
> > know if unwritten extents can appear in the wild).
> >
> > I *cannot* stress this enough: Ext4Pkg is a clean room implementation
> > of ext4 licensed under the BSD-2-Clause-Patent license (which is NOT
> > compatible with GPLv2) and cannot have random Linux kernel
> > bits, or any other incompatibly-licensed project's bits for that matter.
> >
> > Best regards,
> > Pedro
> >
> >
> >> On Wed, Oct 27, 2021 at 2:37 PM qi zhou <atmgnd@outlook.com> wrote:
> >>
> >>> From: "Qi Zhou" <atmgnd@outlook.com>
> >>> Subject: [PATCH] unwritten extent suuport
> >>>
> >>> the real lenght of uninitialized/unwritten extent should be (ee_len
> >>> - (1UL << 15)), and
> >>> all related block should been read as zeros. see:
> >>>
> https://github.com/torvalds/linux/blob/d25f27432f80a800a3592db128254c8140bd71bf/fs/ext4/ext4_extents.h#L156
> >>>
> >>> Signed-off-by: Qi Zhou <atmgnd@outlook.com>
> >>> ---
> >>> Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h | 5 +++++
> >>> Features/Ext4Pkg/Ext4Dxe/Extents.c | 4 ++--
> >>> Features/Ext4Pkg/Ext4Dxe/Inode.c | 5 +++++
> >>> 3 files changed, 12 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h
> b/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h
> >>> index 070eb5a..7ca8eee 100644
> >>> --- a/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h
> >>> +++ b/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h
> >>> @@ -402,6 +402,11 @@ typedef struct {
> >>>
> >>> #define EXT4_MIN_DIR_ENTRY_LEN 8
> >>>
> >>> +#define EXTENT_INIT_MAX_LEN (1UL << 15)
> >>> +
> >>> +#define EXTENT_REAL_LEN(x) ((UINT16)(x <= EXTENT_INIT_MAX_LEN ? x :
> >>> (x - EXTENT_INIT_MAX_LEN)))
> >>> +#define EXTENT_IS_UNWRITTEN(x) (x > EXTENT_INIT_MAX_LEN)
> >>> +
> >>> // This on-disk structure is present at the bottom of the extent tree
> >>> typedef struct {
> >>> // First logical block
> >>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> >>> index 5fa2fe0..21af573 100644
> >>> --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
> >>> +++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
> >>> @@ -332,7 +332,7 @@ Ext4GetExtent (
> >>> return EFI_NO_MAPPING;
> >>> }
> >>>
> >>> - if (!(LogicalBlock >= Ext->ee_block && Ext->ee_block +
> >>> Ext->ee_len > LogicalBlock)) {
> >>> + if (!(LogicalBlock >= Ext->ee_block && Ext->ee_block +
> >>> EXTENT_REAL_LEN(Ext->ee_len) > LogicalBlock)) {
> >>> // This extent does not cover the block
> >>> if (Buffer != NULL) {
> >>> FreePool (Buffer);
> >>> @@ -413,7 +413,7 @@ Ext4ExtentsMapKeyCompare (
> >>> Extent = UserStruct;
> >>> Block = (UINT32)(UINTN)StandaloneKey;
> >>>
> >>> - if (Block >= Extent->ee_block && Block < Extent->ee_block +
> >>> Extent->ee_len) {
> >>> + if (Block >= Extent->ee_block && Block < Extent->ee_block +
> >>> EXTENT_REAL_LEN(Extent->ee_len)) {
> >>> return 0;
> >>> }
> >>>
> >>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Inode.c
> b/Features/Ext4Pkg/Ext4Dxe/Inode.c
> >>> index 63cecec..d691ec7 100644
> >>> --- a/Features/Ext4Pkg/Ext4Dxe/Inode.c
> >>> +++ b/Features/Ext4Pkg/Ext4Dxe/Inode.c
> >>> @@ -151,6 +151,11 @@ Ext4Read (
> >>> // Potential improvement: In the future, we could get the
> >>> hole's tota
> >>> // size and memset all that
> >>> SetMem (Buffer, WasRead, 0);
> >>> + } else if(EXTENT_IS_UNWRITTEN(Extent.ee_len)) {
> >>> + HoleOff = CurrentSeek - (UINT64)Extent.ee_block *
> Partition->BlockSize;
> >>> + HoleLen = EXTENT_REAL_LEN(Extent.ee_len) *
> >>> Partition->BlockSize - HoleOff;
> >>> + WasRead = HoleLen > RemainingRead ? RemainingRead : HoleLen;
> >>> + SetMem (Buffer, WasRead, 0);
> >>> } else {
> >>> ExtentStartBytes = MultU64x32 (
> >>> LShiftU64 (Extent.ee_start_hi, 32) |
> >>> --
> >>> 2.17.1
> >>>
> >
> >
> > --
> >
> > Pedro Falcato
>
--
Pedro Falcato
[-- Attachment #2: Type: text/html, Size: 8757 bytes --]
next prev parent reply other threads:[~2021-10-27 21:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-27 13:37 [PATCH][Ext4Pkg] unwritten extent suuport atmgnd
2021-10-27 14:56 ` Pedro Falcato
2021-10-27 15:44 ` qi zhou
2021-10-27 21:34 ` Pedro Falcato [this message]
2021-10-28 0:43 ` qi zhou
2021-10-28 1:09 ` [edk2-devel] " Kevin@Insyde
2021-10-28 13:57 ` Pedro Falcato
[not found] ` <7A0482AF-274E-474C-80FB-6F9FFFE4F2C3@getmailspring.com>
2021-10-27 15:48 ` qi zhou
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-list 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='CAKbZUD0AJ9HddRsHVPdzPvk6kcDK72Pwm5ACzxj=6OzQaMi7xw@mail.gmail.com' \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox