I've summarized some of the big differences between sdfat and exfat
in linux-next.
1. sdfat has been refactored to improve compatibility, readability and
to be linux friendly.(included support mass storages larger than 2TB.)
2. sdfat has been optimized for the performance of SD-cards.
- Support SD-card friendly block allocation and delayed allocation
for vfat-fs only.
- Support aligned_mpage_write for both vfat-fs and exfat-fs
3. sdfat has been optimized for the performance of general operations
like create,lookup and readdir.
4. Fix many critical and minor bugs
- Handle many kinds of error conditions gracefully to prevent panic.
- Fix critical bugs related to rmdir, truncate behavior and so on...
5. Fix NLS functions
Note, that Samsung is still improving sdfat driver. For instance,
what will be realeased soon is sdfat v2.3.0, which will include support
for "UtcOffset" of "File Directory Entry", in order to satisfy
exFAT specification 7.4.
Thanks!
> -----Original Message-----
> From: Ju Hyung Park [mailto:qkrwngud825@xxxxxxxxx]
> Sent: Tuesday, September 17, 2019 3:04 PM
> To: Greg KH; namjae.jeon@xxxxxxxxxxx; Valdis Kletnieks
> Cc: devel@xxxxxxxxxxxxxxxxxxxx; linkinjeon@xxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; alexander.levin@xxxxxxxxxxxxx;
> sergey.senozhatsky@xxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
>
> On Tue, Sep 17, 2019 at 2:47 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > It's the fact that it actually was in a form that could be merged, no
> > one has done that with the sdfat code :)
>
> Well, I'm more than happy to help if you guys are happy with merging
> the new base.
>
> > What fixes? That's what I'm asking here.
>
> I gave this as an example in my previous email:
> https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657
>
> > How do we "know" that this is better than what we currently have today?
> > We don't, so it's a bit hard to tell someone, "delete the work you did
> > and replace it with this other random chunk of code, causing you a bunch
> > more work in the process for no specific reason other than it looks
> > 'newer'." :(
>
> The new sdFAT base I'm suggesting, is just as "random" as the one
> staging tree is based on.
>
> If exFAT gets merged to Torvald's tree, there will be a lot more eyes
> interested in it.
> If there's a better base, we better switch to it now and prevent
> further headaches long-term.
>
> It's really hard to compare those 2 drivers base and extract
> meaningful changelogs.
>
> But regardless, here are some diff stats:
> <Full diff stat>
> Kconfig | 79 +-
> Makefile | 46 +-
> api.c | 423 ----
> api.h | 310 ---
> blkdev.c | 409 +---
> cache.c | 1142 ++++-----
> config.h | 49 -
> core.c | 5583 ++++++++++++++++++++++++--------------------
> core.h | 196 --
> core_exfat.c | 1553 ------------
> exfat.h | 1309 +++++++----
> exfat_fs.h | 417 ----
> extent.c | 351 ---
> fatent.c | 182 --
> misc.c | 401 ----
> nls.c | 490 ++--
> super.c | 5103 +++++++++++++++++++++-------------------
> upcase.c | 740 ++++++
> upcase.h | 407 ----
> version.h | 29 -
> xattr.c | 136 --
> 21 files changed, 8186 insertions(+), 11169 deletions(-)
>
> <diff-filter=M>
> Kconfig | 79 +-
> Makefile | 46 +-
> blkdev.c | 409 +---
> cache.c | 1142 +++++-----
> core.c | 5583 ++++++++++++++++++++++++++----------------------
> exfat.h | 1309 ++++++++----
> nls.c | 490 ++---
> super.c | 5103 ++++++++++++++++++++++---------------------
> 8 files changed, 7446 insertions(+), 6715 deletions(-)
>
> > I recommend looking at what we have in the tree now, and seeing what is
> > missing compared to "sdfat". I know a lot of places in the exfat code
> > that needs to be fixed up, odds are they are the same stuff that needs
> > to be resolved in sdfat as well.
>
> Would there be any more data that I can provide?
> It's really hard to go through the full diff :(
>
> Thanks.
