Re: [PATCH] staging: exfat: add exfat filesystem code to

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Sep 18, 2019 at 11:35:08AM +0900, Namjae Jeon wrote:
> 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

Those are all wonderful things, any chances you can point out the
individual commits that reflect these bugfixes?

> 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.

If Samsung is going to continue to keep its internal tree for this
driver, there's no way we can take a code dump today and expect things
to keep in sync.

If Samsung agrees to do development of this codebase upstream in the
kernel tree, I will be glad to consider moving to this codebase instead
and working together on it.  Otherwise it makes no sense as things
instantly diverge with no way of keeping in sync (we only can commit to
one tree, while you can in both.)

If Samsung wishes to use their sdfat codebase as the "seed" to work from
for this, please submit a patch adding the latest version to the kernel
tree and we can compare and work from there.

thanks,

greg k-h



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux