From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out02.hibox.biz (out02.hibox.biz [210.71.195.45]) by mx.groups.io with SMTP id smtpd.web12.5270.1635383395218218651 for ; Wed, 27 Oct 2021 18:09:56 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: insyde.com, ip: 210.71.195.45, mailfrom: kevin.davis@insyde.com) IronPort-SDR: GdSVAkk8YU/GDBxVS4RoTCw3BY9mtPztJXTdp53QPvrWtc07wK/7Jr1sr55AdTsGolKdsbW+KH fHF5I2JSbojg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CEAAD39Xlh/ww0GKxaHQEBAQEJARI?= =?us-ascii?q?BBQUBSYE+BgELAYEggX8sgRaER5EQA4gwgkWFfoswgSUDVAsBAQEBAQEBAQE?= =?us-ascii?q?EBTkIBAEBgguCdQIggjMmNgcOAQIEAQEBEgEBBgEBAQEBBgSBJIVoDYZCAQE?= =?us-ascii?q?CAgEjBCcrBRYMAQQEAQEBIAEJAgQfEB4IBxIdBIJLBAEBglUDDhEfrEh6fzI?= =?us-ascii?q?aAmWDTgGBGoI5DWaBUxCBOgGBUxKFKA0BgR+BW4QAggxEgRUnHHltgQE+giF?= =?us-ascii?q?CAQECGIFGF4MBN4IuBI4CIGMrAQoRECAPITAFCwk0GxoqBjYSkUuDCYs+YIE?= =?us-ascii?q?niWORCjxnB4M1hUiFA45EhWoFLYNqgUmKKIYuAxeQfZBthR8fhEwlh2KDRpB?= =?us-ascii?q?EYwGERoFnAUEeDoEgTSNQKgGCPgk1ExmOOwEVg1CCZIFahkBUCy0CBgEKAQE?= =?us-ascii?q?DCZJvAQE?= X-IronPort-AV: E=Sophos;i="5.87,188,1631548800"; d="p7s'?scan'208,217";a="48273047" Received: from unknown (HELO hb3-BKT202.hibox.biz) ([172.24.52.12]) by out02.hibox.biz with ESMTP; 28 Oct 2021 09:09:50 +0800 IronPort-SDR: nBjywcQLtupmYK6hf752gabIGYd/BR8y+Pe6vNTX+sPEUprMvNr2BXuKHMbvpIpvypcUgWDWbY L8AsfzZUEoLQ== Received: from unknown (HELO hb3-BKT102.hibox.biz) ([172.24.51.12]) by hb3-BKT202.hibox.biz with ESMTP; 28 Oct 2021 09:09:50 +0800 IronPort-SDR: hEfon6Y3ZHMzgVDmdtvv+73lm46+wq5WAwOn1qgyzrPBY+yfVuftARJsYL0GX82peRT5Ir6Pev xwWlS1S5YusA== Received: from unknown (HELO hb3-IN05.hibox.biz) ([172.24.12.15]) by hb3-BKT102.hibox.biz with ESMTP; 28 Oct 2021 09:09:50 +0800 IronPort-SDR: +BgtLJ2tBeJQhGcbFGxEHt5QzcASdR4RaVHRJd8Mboh0DgYHzRZyczRRVJ89JRhxhOuuGYeh1C g+7sU6qJce/LEixE0S7Bed5uqWFu9fGRg= X-Remote-IP: 172.24.141.136 X-Remote-Host: No hostname X-SBRS: None X-MID: 70184401 X-Auth-ID: kevin.davis@insyde.com X-EnvelopeFrom: kevin.davis@insyde.com IronPort-Data: =?us-ascii?q?A9a23=3AmzzWfK7QrNlWDem9MnqcjQxRtOPGchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmYdWmuOOvrYZWf9e95xYIyw8BhSuJTQyIdqTQNvqH1gQ?= =?us-ascii?q?iMRo6IpJ/zAdR6oYHn6wu4v7a5fAkx3huDodKjYl1fQ+UWgNKbPt3552f3aT?= =?us-ascii?q?7bwErecaCF3Xh5oRWEqjhc6w7w1hYthgN6YBQKRuIOp/52GYQX9gzMkYHgJ7?= =?us-ascii?q?6+jqQ90uKigsj0vuFFjN+tAu0XTliVIAZ9GffOxInL0T5N6BOm/Q+qfnri18?= =?us-ascii?q?nmAp0UsDMi0nru9eUoPG+aAMQ+Lg3tQeq6jnhkS/XBii/9hbKIRMB4FhS+Ik?= =?us-ascii?q?tZ9zMR2maaxEQp5bLfRnOk9UgVDF30sN6Nx/rKac2O0ttaezhGbfnbhn6duA?= =?us-ascii?q?UUxMdFK8+p7GzgQp+cdNCgGahGOgf7wyaqjTuQ13pYvK8ziPYU+vHB8zGiHV?= =?us-ascii?q?K54EcuTG/nHtY1CwTM9psFSBvKPNcMWZA1mYAnEf0MdN1oSE8tuwrWli3zkK?= =?us-ascii?q?mIB8QCYqK8suzfkzAF117WwYsHefcaHRJkNk0uVzo4cE78VOTlHcozAoda52?= =?us-ascii?q?ij03LaWxXmkANl6+ICQrZaGvnXCnwT/NzVGDTNXkdHh4qKPc4o3x348o0LCn?= =?us-ascii?q?oBunKCfdeQRajXjyJKyUrHwbPILewEywFnlJqM5eG91DEBcJtJKQIROWMPb2?= =?us-ascii?q?VUXOlG1c9PBXVSDsZWOTG6F/bOVoDWufyENNWsPDcMGZVJauZ+5/Mdq0kuJF?= =?us-ascii?q?409eEK2poSd9TXYwD2UrS54i7wNjNUj1qOg7FzKxTmro/AlSyZqvlyHAj79s?= =?us-ascii?q?GuVY6bgPeRE82Pz7vteLYDfQlCfvWMsms6F/ewDS5qKkUSwrE8ldF2yz6/aa?= =?us-ascii?q?nuG3Rg2Q8Bnrm/zk0NPtLt4uFlWTHqF+O5dEdMxXHLuhA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AbY1+Vq+QaQ2S5dk6E3Ruk+DTI+orL9Y04l?= =?us-ascii?q?Q7vn2ZhyY0TiX+raqTdZUgviMc5wxxZJhNo7+90ey7L080i6QFgrX5TI3OYO?= =?us-ascii?q?COggLBEGgh1/qB/9SKIUHDH4BmpMJdmtBFebnNMWQ=3D?= Received: from unknown (HELO smtpclient.apple) ([172.24.141.136]) by hb3-IN05.hibox.biz with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2021 09:09:47 +0800 Mime-Version: 1.0 (1.0) Subject: Re: [edk2-devel] [PATCH][Ext4Pkg] unwritten extent suuport From: "Kevin@Insyde" In-Reply-To: Date: Wed, 27 Oct 2021 18:09:44 -0700 Cc: Pedro Falcato Message-Id: <7C76DD82-76B7-4C68-89E7-3CC0B74AE341@insyde.com> To: devel@edk2.groups.io, atmgnd@outlook.com X-Mailer: iPhone Mail (19B74) X-Groupsio-MsgNum: 82778 Content-Type: multipart/signed; boundary=Apple-Mail-D43EA1F1-862E-43EC-8F13-063FEEEE4E26; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit --Apple-Mail-D43EA1F1-862E-43EC-8F13-063FEEEE4E26 Content-Type: multipart/alternative; boundary=Apple-Mail-C51F4CAD-2302-4858-ACFB-C09D3D0C594C Content-Transfer-Encoding: 7bit --Apple-Mail-C51F4CAD-2302-4858-ACFB-C09D3D0C594C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pedro, I believe he DID reference Linux source =E2=80=9C 2. I did't look at linux kernel(ext4) berfor send this patch, I c= ant found any offcial document, so I refer to linux source as a standand when send this patch=E2=80=9D Kevin D Davis Security Strategist Insyde Software > On Oct 27, 2021, at 5:43 PM, qi zhou wrote: >=20 > =EF=BB=BFThis line may do come form linux kernel, As you can see in the f= irst > 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 >=20 > 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 >=20 > The debug/fix process, I described here >=20 > 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=3DWzHaBf > diff.efi: https://1drv.ms/u/s!As-Ec5SPH0fuilgMwlg6yNQOFCD1?e=3DGVoKuH >=20 > 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 >=20 >=20 > From: Pedro Falcato > Sent: Thursday, October 28, 2021 5:34 > To: QiZhou > Cc: devel@edk2.groups.io > Subject: Re: [PATCH][Ext4Pkg] unwritten extent suuport=20 > =20 > Hi Qi, >=20 > 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 le= ast a line that's suspiciously similar to Linux's code: >=20 > #define EXTENT_INIT_MAX_LEN (1UL << 15) >=20 > the UL looks redundant to me, since there's no need for it. >=20 > Also, I prefer that you fix the typos yourself and format the patch corre= ctly, including the code. >=20 >=20 > On Wed, Oct 27, 2021 at 4:45 PM QiZhou wrote: > 1. I am not familiar with freebsd, and don know if freebsd get the same i= ssue, > But I do found the freebsd has some code snippets related to unwritten ex= tent, > see: https://github.com/freebsd/freebsd-src/blob/b3f46656393f5c8a6e8305af= eb5e8c3638025c26/sys/fs/ext2fs/ext2_extents.h#L37 > https://github.com/freebsd/freebsd-src/blob/b3f46656393f5c8a6e8305afeb5e8= c3638025c26/sys/fs/ext2fs/ext2_extents.c#L1347 > Is Ext4 is freebsd's default/major file system ? >=20 > 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 >=20 > 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 >=20 > 4. You can fix the typos, My English is not so good >=20 >> On Oct 27 2021, at 10:56 pm, Pedro Falcato wro= te: >>=20 >> Hi, >> =20 >> The patch looks OK despite the typos and lack of proper formatting on >> the commit message. >> =20 >> 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). >> =20 >> 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. >> =20 >> Best regards, >> Pedro >> =20 >> =20 >>>> On Wed, Oct 27, 2021 at 2:37 PM qi zhou wrote: >>> =20 >>>> From: "Qi Zhou" >>>> Subject: [PATCH] unwritten extent suuport >>>> =20 >>>> 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/d25f27432f80a800a3592db128254c8= 140bd71bf/fs/ext4/ext4_extents.h#L156 >>>> =20 >>>> Signed-off-by: Qi Zhou >>>> --- >>>> 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(-) >>>> =20 >>>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h b/Features/Ext4Pkg/Ex= t4Dxe/Ext4Disk.h >>>> index 070eb5a..7ca8eee 100644 >>>> --- a/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h >>>> +++ b/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h >>>> @@ -402,6 +402,11 @@ typedef struct { >>>> =20 >>>> #define EXT4_MIN_DIR_ENTRY_LEN 8 >>>> =20 >>>> +#define EXTENT_INIT_MAX_LEN (1UL << 15) >>>> + >>>> +#define EXTENT_REAL_LEN(x) ((UINT16)(x <=3D 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/Ext= 4Dxe/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; >>>> } >>>> =20 >>>> - if (!(LogicalBlock >=3D Ext->ee_block && Ext->ee_block + >>>> Ext->ee_len > LogicalBlock)) { >>>> + if (!(LogicalBlock >=3D Ext->ee_block && Ext->ee_block + >>>> EXTENT_REAL_LEN(Ext->ee_len) > LogicalBlock)) { >>>> // This extent does not cover the block >>>> if (Buffer !=3D NULL) { >>>> FreePool (Buffer); >>>> @@ -413,7 +413,7 @@ Ext4ExtentsMapKeyCompare ( >>>> Extent =3D UserStruct; >>>> Block =3D (UINT32)(UINTN)StandaloneKey; >>>> =20 >>>> - if (Block >=3D Extent->ee_block && Block < Extent->ee_block + >>>> Extent->ee_len) { >>>> + if (Block >=3D Extent->ee_block && Block < Extent->ee_block + >>>> EXTENT_REAL_LEN(Extent->ee_len)) { >>>> return 0; >>>> } >>>> =20 >>>> diff --git a/Features/Ext4Pkg/Ext4Dxe/Inode.c b/Features/Ext4Pkg/Ext4D= xe/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 =3D CurrentSeek - (UINT64)Extent.ee_block * Partition->= BlockSize; >>>> + HoleLen =3D EXTENT_REAL_LEN(Extent.ee_len) * >>>> Partition->BlockSize - HoleOff; >>>> + WasRead =3D HoleLen > RemainingRead ? RemainingRead : HoleLen; >>>> + SetMem (Buffer, WasRead, 0); >>>> } else { >>>> ExtentStartBytes =3D MultU64x32 ( >>>> LShiftU64 (Extent.ee_start_hi, 32) | >>>> -- >>>> 2.17.1 >>>> =20 >> =20 >> =20 >> -- >> =20 >> Pedro Falcato >=20 >=20 > --=20 > Pedro Falcato >=20 >=20 >=20 >=20 --Apple-Mail-C51F4CAD-2302-4858-ACFB-C09D3D0C594C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pedro,

I believe he = DID reference Linux source

=E2=80=9C 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=E2=80=9D

Kevin D Davis
Security Strategist
Insyde Software



On Oct 27, 2021, at 5:43 PM, qi zhou <atmgnd@outlook.com> wrote:
=
=EF=BB=BF= This line may do come form linux kernel, As you can see in the first<= /span>
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 involuedI think even freebsd has some code from linux, like the second link = I
posted, the freebsd's ext4_ext_get_actual_len and EXT_INI= T_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 thos= e 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 fi= les, but
failed on verfication use some tools I writed, I s= hare it here
md5sum.efi: https://1drv.ms/u/s!As-Ec5SPH0fuil= lwxhIsePY0KBla?e=3DWzHaBf
diff.efi: https://1drv.ms/u/s!As-= Ec5SPH0fuilgMwlg6yNQOFCD1?e=3DGVoKuH

then = I googed to for replacement(on the first, I dont plat to fixed itmyself), But no luck, the all fails on large file read verfication. = But
I noticed the performance of edk2-platforms's ext4 driv= er 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 log= s dump the edk2's read extents to serial on data that did't not
<= span>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<= br>to find the logic about unwritten extents, then did the fix=


From: Pedro Falcato <pedro.f= alcato@gmail.com>
Sent: Thursday, October 28, 2021 5:34<= /span>
To: QiZhou <atmgnd@outlook.com>
Cc: d= evel@edk2.groups.io <devel@edk2.groups.io>
Subject: R= e: [PATCH][Ext4Pkg] unwritten extent suuport
 =
Hi Qi,

If you didn't use the Lin= ux kernel (nor the documentation) as a reference, can you please tell me wh= at you've used? I'm asking because there's at least a line that's suspiciou= sly similar to Linux's code:

#define EXTEN= T_INIT_MAX_LEN (1UL << 15)

the UL lo= oks redundant to me, since there's no need for it.
<= br>Also, I prefer that you fix the typos yourself and format the patc= h correctly, including the code.

On Wed, Oct 27, 2021 at 4:45 PM QiZhou <atmgnd@outlook.com> w= rote:
1. I am not familiar with freebsd, and don know if fr= eebsd get the same issue,
But I do found the freebsd has so= me code snippets related to unwritten extent,
see: https://= github.com/freebsd/freebsd-src/blob/b3f46656393f5c8a6e8305afeb5e8c3638025c2= 6/sys/fs/ext2fs/ext2_extents.h#L37
https://github.com/freeb= sd/freebsd-src/blob/b3f46656393f5c8a6e8305afeb5e8c3638025c26/sys/fs/ext2fs/= ext2_extents.c#L1347
Is Ext4 is freebsd's default/major fil= e system ?

2. I did't look at linux kernel= (ext4) berfor send this patch, I cant
found any offcial doc= ument, so I refer to linux source as a standand
when send t= his patch

3. Yes, unwritten extents are wi= ld used, usally when a file cotains many
zeros, or mark fil= e holes(fallocate, qemu-img...)
You can generate a file con= tains 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 a= ny continuous zeros, like compressed files,
then there will= be no any unwritten extents
unwritten extents are usally s= een in very large files

4. You can fix the= typos, My English is not so good

On Oct 2= 7 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
<= span>the commit message.
<= span> 
But hon= estly, I don't know if this patch is even mergeable considering
<= /blockquote>
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 dri= ver (as I had
done i= n 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-Cla= use-Patent license (which is NOT
compatible with GPLv2) and cannot have random Linux kernel
bits, or any other inco= mpatibly-licensed project's bits for that matter.
 
Best regards,
Pedro
&n= bsp;
  =
= 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
<= /blockquote>
 
the real lenght of uninitialized/unwr= itten extent should be (ee_len
- (1UL << 15)), and
all related block should been read as zeros. see:<= /span>
=
https://github.co= m/torvalds/linux/blob/d25f27432f80a800a3592db128254c8140bd71bf/fs/ext4/ext4= _extents.h#L156
&= nbsp;
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/Ext4Pk= g/Ext4Dxe/Ext4Disk.h
index 070eb5a..7ca8eee 100644
--- a/Features/Ext4Pkg/Ext4Dxe/Ext4Disk.h
+++ b/Features/Ext4Pkg/Ext4Dxe/Ex= t4Disk.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) ((UIN= T16)(x <=3D EXTENT_INIT_MAX_LEN ? x :
(x - EXTENT_INIT_MAX_LEN)))
=
+#define EXTENT_IS_UNWRITTEN(x) (x > = EXTENT_INIT_MAX_LEN)
+
 // Th= is on-disk structure is present at the bottom of the extent tree
=
 typedef struct {
   // First= logical block
di= ff --git a/Features/Ext4Pkg/Ext4Dxe/Extents.c b/Features/Ext4Pkg/Ext4Dxe/Ex= tents.c
index 5= fa2fe0..21af573 100644
= --- a/Features/Ext4Pkg/Ext4Dxe/Extents.c
+++ b/Features/Ext4Pkg/Ext4Dxe/Extents.c
@@ -332,7 +332,7 @@ E= xt4GetExtent (
&n= bsp;    return EFI_NO_MAPPING;
   }
=
 
-  if (!(LogicalBlock >=3D Ext->ee_block &&= Ext->ee_block +
Ext->ee_len > LogicalBlock)) {
+  if (!(LogicalBlock >=3D Ext->ee_block = && Ext->ee_block +
EXTENT_REAL_LEN(Ext->ee_len) > LogicalBlock)) {
     // Th= is extent does not cover the block
     if (Buffer !=3D NULL) {
       Fre= ePool (Buffer);
@= @ -413,7 +413,7 @@ Ext4ExtentsMapKeyCompare (
   Extent =3D UserStruct;
=
   Block  = =3D (UINT32)(UINTN)StandaloneKey;
 
<= blockquote type=3D"cite">
-  if (Block >=3D Extent->ee_block && Block <= Extent->ee_block +
= Extent->ee_len) {
+  if (Block >=3D Extent->ee_block && Block &l= t; Extent->ee_block +
<= blockquote type=3D"cite">
EXTENT_REAL_LEN(Extent->ee_len)) {
     return 0;
   }
 
diff --git a/Features/Ext4Pkg/Ext4Dxe/Inod= e.c b/Features/Ext4Pkg/Ext4Dxe/Inode.c
=
index 63cecec..d691ec7 100644
=
--- a/Features/Ext4Pkg/Ext4Dxe/Inode.c
<= blockquote type=3D"cite">
+++ b/Features/Ext= 4Pkg/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
       Set= Mem (Buffer, WasRead, 0);
=
+    } else if(EXTENT_IS_UNWRITTEN(Extent.ee_len)) {
+     = ; HoleOff =3D CurrentSeek - (UINT64)Extent.ee_block * Partition->BlockSi= ze;
+   = ;   HoleLen =3D EXTENT_REAL_LEN(Extent.ee_len) *
Partition->BlockSize - HoleOff;
+     = ; WasRead =3D HoleLen > RemainingRead ? RemainingRead : HoleLen;<= br>
+      Se= tMem (Buffer, WasRead, 0);
     } else {
=
       ExtentStartBytes =3D MultU= 64x32 (
  =                      = ;     LShiftU64 (Extent.ee_start_hi, 32) |
--
=
2.17.1
 
 
 
--
 
Pedro Falcato
<= /blockquote>

--
Ped= ro Falcato




--Apple-Mail-C51F4CAD-2302-4858-ACFB-C09D3D0C594C-- --Apple-Mail-D43EA1F1-862E-43EC-8F13-063FEEEE4E26 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBSww ggUoMIIEEKADAgECAhACbBWYh2GC4f7M2DAJPr8dMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0yMTA4MTcwMDAwMDBaFw0yMzA4 MTUyMzU5NTlaMEgxHzAdBgNVBAMMFmtldmluLmRhdmlzQGluc3lkZS5jb20xJTAjBgkqhkiG9w0B CQEWFmtldmluLmRhdmlzQGluc3lkZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDVGLBFNzxSeGYJ2kRMfbKCPcigsSF4WqmuE0H5dgrbxQkZ1Eaq1/b+BRb4d/upqcLd48fxLeNG LqkD6hfqyBziu2RkZODOrtzrFxTFrGcSantHOElEM5d6eBwzcquZuOCEKXecV6j6P2AfCXmPLHFK orIBHXnnMfmXe4c0OLI0ykMH3NH+nXK7t7ay+jtNdEayITUVwJeMxgP1q4vaVulH4Su5KmAhEfPP Oa4DILrT58qFORscID/v3QSM8mIM4JYPQynf1EBeSU3CJI8v5tBx16PLBAvBHPDIgof2nP7g+pET 2wc8YK6lP0lLKq9rgPs51+EQaSwMQ2ZvD23RvWb9AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUnt0APaVjrdr2yod8fpTc4jrJ9wQwDAYDVR0T AQH/BAIwADAhBgNVHREEGjAYgRZrZXZpbi5kYXZpc0BpbnN5ZGUuY29tMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAEB MCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+ MD2gO6A5hjdodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0Et ZzMuY3JsMD2gO6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJl ZElEQ0EtZzMuY3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNl cnRTSEEyQXNzdXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBEtNi+Fc31CwQiIYwk3jDP YkD+YiMgfhrLz3Mi/sgUEUdgZSZ4OV92PEf7QBYiQlWGiMidOAVlN4CtxiUMo/Si2iFRq/drEdw0 8mNp49L/ujXbOXFj1znyT/fIB/xtwSonpQp+llZPPhFC+RgyvBeu+XZ25x8gE5PB18tlNJWjhcyw uUv5TYtywV3EG9LS1xjq3EGDCUJyAl7gz3KDqV5oBixKREeXco/fw0UcyoQ+qNeENK+0uH7stz+S 0u/IF29H4WYXJyiY/HngsXZhNMH1+4bO8b9lxmS+HQPZu3ZSezgYNYnGKB0qtm6rbYLgGnjLn8dG NNVR9XwiLURe2vZAMYIDKTCCAyUCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNl cnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEy IEFzc3VyZWQgSUQgQ0ECEAJsFZiHYYLh/szYMAk+vx0wDQYJYIZIAWUDBAIBBQCgggGBMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMTAyODAxMDk0NFowLwYJKoZI hvcNAQkEMSIEIOQWzeHAh2MorQpAiQCG5H/EKYMP7TpDsYmFu/iO/sz/MIGIBgkrBgEEAYI3EAQx ezB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAmwVmIdh guH+zNgwCT6/HTCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0 IFNIQTIgQXNzdXJlZCBJRCBDQQIQAmwVmIdhguH+zNgwCT6/HTANBgkqhkiG9w0BAQsFAASCAQCm 2XwpgZfTqR9mBV7bCHkxWMvu8xg4/lqWwJGdMarCq+5T78wRGk5tPJI1EmRk2Y8eU+bCPDeCegX+ zjL9ffBn5Bf5KT3QRTDgtXApjBpFy58L5+VW5LGjHowmI+O3c1EFY4J+ulDd6dDkeDDgrTKf3Enf v8nR6wnA4WdBwNyXFrV2+K21AnQJ7y77hJNSAIPXeUfT6EYvMfIAXfAQ6XAAYipgQo02tayElDPe ICoxxvbLthpDdwtImcNU5gJDG9jFpHcFDbzIhupPTQ+2ZUW7he+SxBfvpHseze+BmrP7sr31qr/r kzSxBCIhAOqbkCpZNkQPDE2QqNnW5YzdsmncAAAAAAAA --Apple-Mail-D43EA1F1-862E-43EC-8F13-063FEEEE4E26--