Small Files vs Large Files

Status
Not open for further replies.

sloppy69

Cadet
Joined
May 27, 2014
Messages
2
I have a question about the deference in file transfer speed with large files vs small files.

For example I was moving some Blu-ray rips from my desktop to the FreeNas box and was getting about 109 MB/s according to windows, it was about 200 or so GB of data the files were around 25~30 GB each.

I also moved about 100 Gb of music to the Nas box and my transfer speed is cut in half around 40-55ish MB/s

Why is this ?

Does it have to do with the data being scattered across the drive with smaller files?


My Nas

Supermicro 1155 mobo
E3-1280v2 cpu
16Gb ddr3 Ecc unreg memory
LSI 9240 with 8 1TB seagate Hds
 

bestboy

Contributor
Joined
Jun 8, 2014
Messages
198
If you have to transfer either
  1. lots of small files or
  2. huge files
I'd suggest to use FTP.

about #1
  • CIFS can only transfer 1 file at a time.
  • FTP can transfer multiple files concurrently.

about #2
  • If you cancel a 30 GB CIFS file transfer at 90% complete, you have to retransmit the whole 30 GB file.
  • FTP can resume file transfers. It would just continue where it left off and send the remaining 10%.

TL;DR: Don't use CIFS when there's work to be done.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Riight. I'll have to respectfully disagree with you on every aspect.

FTP has no checksumming of the data packets. TCP/IP uses CRC32 which is very poor at detecting problems. I've seen *many* files corrupted on LANs with high end gear just because packets get garbled en-route. CIFS on the other hand has it's own checksums(which is why the CPU load is much higher) but the data has almost no chance of being corrupted in transit.

Small file transfers suck because you have to do extra disk reads(read: head movement) when handling the data. Also on the destination the disks have more work because you must write the file data as well as the metadata and TX/TXG. Head movement is the major penalty and trying to do concurrent transfers is only going to make things much worse.
 

bestboy

Contributor
Joined
Jun 8, 2014
Messages
198
Well, yes FTP has no checksum like most application layer protocols: NFS, HTTP/HTTPS, WebDAV... [1],[2]
Those protocols usually delegate error detection to protocols of the layers below. From bottom up there is
  • link layer: 32 bit checksum on the Ethernet frame
  • network layer: no checksum in IPv4 (there's just a 16 bit header checksum)
  • transport layer: 16 bit checksum on the TCP segment
I guess that's fine unless there are multiple adjacent bit errors.

[1] I could not find any indication that CIFS is any different in this regard. There is no checksum in the SMB header. Any further information about error detection in CIFS would be quite welcome.
[2] iSCSI is the only application layer file transfer protocol I know of that has a checksum (CRC32c)
 

sloppy69

Cadet
Joined
May 27, 2014
Messages
2
Thanks for the info Cyberjock "also all the other post, they are great and helpfull" and bestboy. I was kinda thinking it had something to do with hard drive limitations.
 

solarisguy

Guru
Joined
Apr 4, 2014
Messages
1,125
@sloppy69: Not just a hard drive limitation. Handling of metadata slows things down, too.
 
Status
Not open for further replies.
Top