Support fast space allocation? about exfat HOT 7 OPEN

Is there anything new about this topic? Problem still exists, makes ExFat as underlying file system unusable.

from exfat.

bump...
Problem still exists :(

from exfat.

Same problem here!

After I connect to a Samba share from Windows client and attempt to copy large file there (on the exfat drive), it starts by truncating the file first. Because the truncate is slow (it's via USB 2), Windows client timeouts (and reports error) if the actual transfer doesn't start within 20 seconds.

Tested with both exfat-fuse and Linux Kernel 5.4's exfat (non-fuse).

So when sending 2 GB from Windows Explorer to a Linux+Samba+exFAT computer, 4 GB are actually written:

• 2 GB of null bytes for the initial truncate
• 2 GB for the actual data

It doubles the transfer time.

Anyone an idea?

from exfat.

Proposal: a method to request allocation some sectors without writing zeroes to new blocks.

Well, looks like the infrastructure (kernel, FUSE and programs) just isn't ready for such feature.

Possible mechanism 4:
Implement FUSE 2.9.1 operation fallocate and add an optional mount parameter that will disable data zeroing for this particular call. Some programs may break though.

Possible mechanism 5:
Zero data using discard (trim) command when it's supported by the device (and sets flash memory blocks to 0). Hopefully it will be faster.

Until then I have to waste some SSD write cycles and wait somewhat longer.

If SSD controller supports data compression, it hardly writes anything to flash in this case.

from exfat.

Option (4) would be probably the easiest to add/use but it is a violation of the interface and may break programs.

Option (5) is better than nothing, but I am not sure if it works on the USB disk enclosure.
SSDs with data compression are solving problems on the wrong layer, I believe that only (some?) Sandforce SSDs do this hack.

from exfat.

I had intention to run Samba share of a exfat formatted external drive but this issue is what prevents me to do that.

After I connect to a Samba share from Windows client and attempt to copy large file there (on the exfat drive), it starts by truncating the file first. Because the truncate is slow (it's via USB 2), Windows client timeouts (and reports error) if the actual transfer doesn't start within 20 seconds.
Transferring the file from macOS is ok. Windows hosted share on exfat is also working fine - which I don't get - is it SMB version thing or truncate implementation in Windows?

https://bugzilla.samba.org/show_bug.cgi?id=3583
http://www.gossamer-threads.com/lists/linux/kernel/683607

from exfat.

is it SMB version thing or truncate implementation in Windows?

Can be both.

A possible solution that comes to my mind:

1. On truncate set size to the desired value and valid_size leave intact. Do not initialize allocated blocks.
2. On write beyond valid_size adjust it accordingly. Initialize blocks between old and new valid_size if they were not overwritten.
3. On read return zeros for blocks beyond valid_size.

FS should be in a consistent state during all those operations while avoiding extra initialization of blocks that will be overwritten soon. But this would be quite a complex change.

from exfat.