Amahi Forums

I just replaced the aging WHS install on my server with a fresh new Amahi install, and so far I'm loving it except for one small detail. I'm trying to migrate all my data from the NTFS volumes to a Greyhole pool. I'm connecting via VNC to my HDA to do the copying. I mounted the SMB shares locally using the mount_shares_locally script I found in the Wiki. When I move the files to /mnt/samba/Whatever, I'm getting extremely slow transfer rates (8-10MB/sec). But here's the weird thing. If I connect to the share from within the Gnome file manager (Go -> Location -> smb://hda/Whatever), moving the same set of files suddenly jumps to 30-32MB/sec. And If I try copying files directly to the drive (/var/hda/files/drives/sdc1/Whatever) I can get 60-65MB/sec. But here's where it gets even weirder. If I copy files from my Windows desktop to the server via Gigabit Ethernet, I can copy files at 60-65MB/sec again.

I've been trying a few things to see if they help. I tried unmounting the share and remounting with the hostname instead of localhost IP, but that slowed performance even more. I also tried the external IP (192.168.1.50) with the same results. It's the same results across multiple shares as well. It doesn't seem to matter if a share's landing zone is on a pool drive or not.

I realize this is more of a temporary problem for me. Once I migrate my data, I shouldn't be copying this large a volume of data at once any more, but it would be nice to finish copying the data this year. I still have roughly 15TB of data on 7 drives to move. Any help anyone can provide would be greatly appreciated. Thank you in advance.

I too am experiencing slow performance, copying from one share to the other (eg /mnt/samba/Share1 to /mnt/samba/Share2). It's averaging at 7.1MB/sec, and it's also taking up about 60-70% CPU on average while it's doing this! I too initiated the copy via VNC, but that shouldn't be an issue, should it? I wouldn't have thought so, as the machine I initiated it from was put to sleep during the copy, and it still continued copying at the same rate.

I assumed that this would be the fastest way to copy the files over. I'll try your other method next time (ie via smb://hda/Share1). But what I find confusing is why the performance would be even faster when files are copied over the network??

If using Greyhole, try installing the mount_shares_locally script. It can be found in the wiki.

http://wiki.amahi.org/index.php/Mount_Shares_Locally

Then when copying files, do it to the shares vs the /mnt/share. You should always work with the shares (/var/hda/files/sharename, not the samba mount in my opinion.

If using Greyhole, try installing the mount_shares_locally script. It can be found in the wiki.

http://wiki.amahi.org/index.php/Mount_Shares_Locally

Then when copying files, do it to the shares vs the /mnt/share. You should always work with the shares (/var/hda/files/sharename, not the samba mount in my opinion.

What you're saying is against whats written in the wiki that you linked to: "Greyhole data should only be accessed through shares, so mounting those shares locally is an easy way to work with Greyhole data safely."

What this means to me is that you mount your /var/hda/files/sharename as /mnt/samba/sharename and then only write to this share via /mnt/samba/sharename.

Please advise on which approach is correct. My internal copy speed from an internal hard drive to smb share on another internal hardrive is about 21MB/sec

Unfortuantely I am no Greyhole expert, so what I have indicated is based on my experiences.

The wiki is a little misleading. I have always worked with files on my box via the share (i.e. /var/hda/files/share). Maybe that was incorrect, but I have never had any issues. I have heard folks working with the /mnt/samba/shares area as well. The main thing I guess is that you don't mess with files in the gh directories.

Typically slow copy performance is network related. Not sure if that is your case, but google might point you in the right direction.

Unfortuantely I am no Greyhole expert, so what I have indicated is based on my experiences.

The wiki is a little misleading. I have always worked with files on my box via the share (i.e. /var/hda/files/share). Maybe that was incorrect, but I have never had any issues. I have heard folks working with the /mnt/samba/shares area as well. The main thing I guess is that you don't mess with files in the gh directories.

Typically slow copy performance is network related. Not sure if that is your case, but google might point you in the right direction.

No offense, but your response does not inspire confidence since at least two wiki entries(including this one http://wiki.amahi.org/index.php/Greyhole ) plus numerous sources online describing greyhole specifically warn against direct(not through smb share) access to GreyHole-pooled files.

I am sorry if my response was misleading or incorrect. I rarely mess with files directly on the HDA.

This is probably how I did it, just did not remember.

What this means to me is that you mount your /var/hda/files/sharename as /mnt/samba/sharename and then only write to this share via /mnt/samba/sharename.

That is what the script does. Sorry if I confused or mislead you. Honestly, that was not the intent.

Make sure you enable write cache in the BIOS.

Before I did this I was getting 4-5mb/s and now I'm getting in excess of 60-70mb/s

Same problem here. I am also doing everything over the gigabit network from the windows box as it is much faster than doing it locally.

I am hoping that the new samba version in Fedora 16 will fix this issue.

so i am sure someone will disagree with me here but....

there is really little "danger" with working directly with the /var/hda/files/ShareName directories vs. the samba share that i can see.

The biggest difference is when Greyhole "deals" with them. If you use the samba shares, samba logs the file write, greyhole sees it and makes it's copies and sym links,

If you use the direct share, Greyhole waits until the next --fsck is run.

I think using samba has some performance sacrifices during the file transfer from my experience.