External Hard Drive Interaction

Hello,

I have no idea what group this post should be in, since it seems to span several areas. So forgive me if its in the wrong place.

When I copy a large file (411MB) from my Windows PC to a linux PC that has a USB FAT32 external drive connected, someone seems to be caching (spooling) data to the hard drive of the linux PC. I am trying to figure out who is doing this and what can be done to stop or minimize the result of it.

I have encrypted partitions on the linux PC. When the copy is done from the Windows PC to the external drive connected of the linux PC, I see kcryptd jump up to the top of the top output and the system becomes unresponsive until the copy is done.

My setup is like this:
Windows PC --- samba --- Linux PC --- USB --- external drive (FAT32)

More info to cloud the issue:
---- USB --- external drive (NTFS) OK
---- eSTATA ---- external drive ( FAT32, NTFS) OK
Samba - 3.0.14 and 3.0.37
Kernel - 2.6.18

Anyone got a suggestion as what is causing this?

Thanks
Larry

From the Linux system, see what options are associated with the mount of the USB FAT32 volume. Post the line of the mount output here.

Here is the output from mount:

/dev/sdb1 on /data/drives/USB_drive1_My Book type vfat (rw,nosuid,nodev,noexec,gid=104,fmask=0000,dmask=0 000,codepage=cp437,iocharset=iso8859-1)

Quote:

---

Originally Posted by lhayes

Here is the output from mount:

/dev/sdb1 on /data/drives/USB_drive1_My Book type vfat (rw,nosuid,nodev,noexec,gid=104,fmask=0000,dmask=0 000,codepage=cp437,iocharset=iso8859-1)

---

Ok. The drive is mounted without the sync option, so when Windows copies to the samba share on Linux, it is cached by the Linux operating system and then written to disc, encrypting it as it does so. This is called write-behind caching. If you enable the sync option on the device when it is mounted, then it will write directly thru the cache to disc. What that means is that your Windows copy operation will be noticeably slower as it will have to wait for Linux to finish the encryption and data writing to disc. You can try that and see if the performance is acceptable to you and your users. Your Linux system will still appear unresponsive until the data gets to the device because of the CPU overhead caused by the encryption server. To fix that, you can reduce its priority by increasing its 'nice' value using the command renice +5 -p kcryptd-pid where kcryptd-pid is the process id of kcryptd. That will give more CPU time to other processes. You can set the nice value from -20 (most favorable scheduling) to 19 (least favorable). The higher the value, the lower the priority of the process. You can experiment with different values and see where the "sweet spot" is with regard to performance of the encrypting and data copying vs. the responsiveness of the system to user activities. That said, multi-core processors help a lot... :-)

Thanks for your suggestions.

The sync option did unlock the system during the copy, but like you said, it slowed the copy, took almost twice as long.

renicing kcryptd caused the copy not to complete, when using async on monut.

Do you know where the kernel is caching on the disk?

I would like to get the async way working as I don't want to take the performance hit. I might be able to turn off encryption where the caching is done.

Thanks
Larry

The OS caches disc writes in kernel space. I don't know how the encryption program pulls data out of the kernel, but it seems that it is getting preempted by other processes when you renice it, hence the copy is failing to finish, so that may not be a good idea. It was worth a try. How many cores and cpus does your system have?

When I used the term linux PC, it was in a general way. The linux box is a media gateway/router with a hard drive. 1 CPU, an amcc ppc. So not alot of processing power.

I guess my next thing to try is to make the swap partition un-encrypted, as I am hoping that is where the kenerl is writing to disc.

Thanks
Larry

Ah! So it is a Linux based NAS (network attached storage) unit. Something like a Buffalo TeraStation, or similar? In any case, it is unlikely that disc writes are being cached to the swap space as that sort of negates the entire purpose of write-behind cache - to only write the data to disc in the most efficient manner after getting as much data accumulated in memory as it can first. That way the driver can optimize disc seeks and put down as many contiguous sectors in one physical write as the disc supports.