public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Kevin@Insyde" <kevin.davis@insyde.com>
To: devel@edk2.groups.io, atmgnd@outlook.com
Cc: Pedro Falcato <pedro.falcato@gmail.com>
Subject: Re: [edk2-devel] [PATCH][Ext4Pkg] unwritten extent suuport
Date: Wed, 27 Oct 2021 18:09:44 -0700	[thread overview]
Message-ID: <7C76DD82-76B7-4C68-89E7-3CC0B74AE341@insyde.com> (raw)
In-Reply-To: <SYZP282MB325278B47EA173101A32E468C9869@SYZP282MB3252.AUSP282.PROD.OUTLOOK.COM>


[-- Attachment #1.1: Type: text/plain, Size: 8377 bytes --]

Pedro,

I believe he DID reference Linux source

“ 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”

Kevin D Davis
Security Strategist
Insyde Software


> On Oct 27, 2021, at 5:43 PM, qi zhou <atmgnd@outlook.com> wrote:
> 
> This line may do come form linux kernel, As you can see in the first
> link I refers says this number (1UL << 15) is kind of magic number. If
> you write somethimg linux standanrded, It is hard to keep abosultely no
> any linux involued
> I think even freebsd has some code from linux, like the second link I
> posted, the freebsd's ext4_ext_get_actual_len and EXT_INIT_MAX_LEN are
> exactly the same as linux
> 
> It is ok if it's considering as not mergeable, I think it is also good
> just as a reference on the mailinng list, to those people who need to
> read very large files
> 
> The debug/fix process, I described here
> 
> on the first, I use vbox's ext4 uefi driver to read large files, but
> failed on verfication use some tools I writed, I share it here
> md5sum.efi: https://1drv.ms/u/s!As-Ec5SPH0fuillwxhIsePY0KBla?e=WzHaBf
> diff.efi: https://1drv.ms/u/s!As-Ec5SPH0fuilgMwlg6yNQOFCD1?e=GVoKuH
> 
> then I googed to for replacement(on the first, I dont plat to fixed it
> myself), But no luck, the all fails on large file read verfication. But
> I noticed the performance of edk2-platforms's ext4 driver is most best
> of all those uefi ext4 drivers
> I did not found a working one, so I need to fix it. First I did some
> guess and research, and then I added
> some logs dump the edk2's read extents to serial on data that did't not
> match, (the diff.efi tool I write will stop reading when data dismatch)
> I compare those log dump to linux's 'filefrag -v"'s ouput, It is easy
> to found the difference, then I google
> to find the logic about unwritten extents, then did the fix
> 
> 
> From: Pedro Falcato <pedro.falcato@gmail.com>
> Sent: Thursday, October 28, 2021 5:34
> To: QiZhou <atmgnd@outlook.com>
> Cc: devel@edk2.groups.io <devel@edk2.groups.io>
> Subject: Re: [PATCH][Ext4Pkg] unwritten extent suuport 
>  
> 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 #1.2: Type: text/html, Size: 22866 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2199 bytes --]

  reply	other threads:[~2021-10-28  1:09 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
2021-10-28  0:43       ` qi zhou
2021-10-28  1:09         ` Kevin@Insyde [this message]
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=7C76DD82-76B7-4C68-89E7-3CC0B74AE341@insyde.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