Hi Andrew,
As I studied the EnhancedFatDxe, it won't increase any size when using
full-cache. So size will not be a problem.
I have also thought about the power issue. It might be the owner's concern.
But it's not very convincing, because:
1. abruptly power loss is an extreme case. No matter using a full-cache
mechanism or a partial-cache mechanism, it won't make much difference.
2. better performance means it uses less time to read/write file, which
means less likely to let file accessing be interrupted by an abruptly power
loss.
3. in my experience, we pursue more robustness in run-time, but pursue more
speed-up in boot time. I see many error-logging and error-correction
mechanisms are only registered during boot, but actually work to make the
system more robust during run-time.
So, I still believe that using full-cache mechanism in FAT driver is of
more benefit.
Anyway, it's not quite an important thing in EFI boot process. I just..very
confused.. because I believe there must be some consideration for the owner
to choose not cache ALL.
I need to be as much careful as I can when I have to write another file
system driver..
Many thanks for your suggestion! Really appreciate it! :)
Best Regards,
Sheldon
2014-12-20 3:00 GMT+08:00 Andrew Fish <af...@apple.com>:
> Sheldon,
>
> I think the person that implemented this, a long time ago, is on vacation
> for the holidays.
>
> It is important to remember the FAT driver is required to boot by EFI and
> thus the size of the driver is also a constraint. It has to fit in the
> FLASH.
>
> It is also important to remember that EFI’s main job is to quickly boot
> the system. Thus there is no mechanism for an orderly shutdown like the OS.
> When you hit the power button in the OS it generates an ACPI event and the
> OS does an orderly shutdown so the FAT driver can flush any caches (etc.),
> in EFI the power just goes away. So the EFI FAT driver may trade off
> performance to be more robust.
>
> Thanks,
>
> Andrew Fish
>
> On Dec 19, 2014, at 1:04 AM, Sheldon Lu <lxd5...@gmail.com> wrote:
>
> Hi Sergey,
>
> Thanks for your reply!
>
> My opinion is:
>
> *First*, Enhanced FAT driver assigns 512KB(32KB/Page * 16Pages) to FAT
> Cache and 4MB(64KB/Page * 64Pages) to Data Cache.
> The Cache size is fixed. So full cache will not use more memory.
>
> *Second*, I think cache mechanism should be used to speed up accesses to
> ranges that overlap the cached ranges.
> Let me explain this:
> (1) When you read/write 63~64KB, it actually read/write 0~64KB. That
> is 1:63(1 portion for use and 63 may be wasted).
> (2) When you read/write 64~128KB, whether you cache it or not, you
> have to put the data in a memory buffer(read from disk to buffer or write
> the buffer to disk).
> That means there is no “waste” if you put 64~128 in cache. And next time,
> when you read/write no matter 63~129KB or 63~70KB or 0~192KB, all will hit
> in cache!
>
> So I’m still very confused. It seems to me that “full” cache mechanism is
> “full” benefit.
>
> Looking forward to more discussion!
>
> Thank you
> Sheldon
>
> *From:* Sergey Isakov [mailto:isakov...@bk.ru <isakov...@bk.ru>]
> *Sent:* Friday, December 19, 2014 3:20 PM
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* Re: [edk2] a question about cache mechanism in EnhancedFatDxe
>
> Hi,
> I may propose that read data done by 64kb block. So to read first data
> 63-64 the driver must read 0-64 and then cache 0-63 for other use.
> The same for tail data. The driver read more then needed and redundant
> data is cached.
> The is no full cache mechanism to speedup data and cache size is small.
>
> Enjoy.
>
> On 19.12.2014, at 6:33, Sheldon Lu wrote:
>
>
> Hi All,
>
> Is there any one can help answer my question ?
> I really need to understand why and explain this to my custmer.
> Please share your ideas or give me some clues if any one knows the answer.
>
> Really thank you!
>
> Sheldon
>
> *From:* Sheldon Lu [mailto:lxd5...@gmail.com <lxd5...@gmail.com>]
> *Sent:* Thursday, December 18, 2014 10:32 AM
> *To:* edk2-devel@lists.sourceforge.net
> *Cc:* jljus...@intel.com; ruiyu...@intel.com; GaryLi(李俊); KasalinYi(易花中);
> RuiDai(戴潇睿)
> *Subject:* a question about cache mechanism in EnhancedFatDxe
>
>
> Hi guys,
>
> I am studying the EnhancedFatDxe driver recently. I met a question when
> looking into *FatAccessCache()* in *DiskCache.c*. As the "Routine
> Description" says:
>
>
>
> *"2. Access of Data cache (CACHE_DATA):The access data will be divided
> into UnderRun data, Aligned data and OverRun data;The UnderRun data and
> OverRun data will be accessed by the Data cache,but the Aligned data will
> be accessed with disk directly."*
>
> I'm very confused with "*the Aligned data will be accessd with disk
> directly*". I can't understand why it only caches "unaligned" data but
> exclude the possiblity to cache "aligned" data ? Does it discount the
> performance ?
>
> An example to show how it works:
>
> If I want to read the data from offset 63KB to offset 129KB(these
> offsets are relative to the Root directry). As the cache alignment is 64KB
> in FAT Data Region, so the data is divided into 3 parts:
>
> 63KB~64KB … 64KB~128KB … 128KB~129KB
>
> The current cache mechanism of EnhancedFatDxe only caches the
> accesses to “63KB~64KB”and “128KB~129KB”,but let the access to
> “64KB~128KB”goes to disk directly!
>
> I’m very confused why it only caches the head and tail but leaves the main
> body behind ?
>
> Any one knows why it is designed like this ? Isn’t it better to cache ALL
> datas without discrimination ?
>
> Looking forward to your reply!
> Thank you so much!
>
> B.R.
>
> Sheldon
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
