2

We just got an AWS account, and I was testing EFS. I created an EFS, mounted it on a Amazon Linux instance, and set it up to be shared in samba. I was then able to map the share as a drive in Windows 7 and Windows Server 2012, but everything associated with it is INCREDIBLY slow (viewing files, creating files, viewing the share properties - everything). I think this is due to the mount being 8 EXAbytes.

Is there a way to resize the share or break it into smaller pieces in either mounting it in the instance or in samba?

Is there a way to resize the efs directly? We will never use 8 exabytes!

Is there a way to tell if it's something else that's making it slow other than the size?

We really need to be able to map this as a drive in windows.

Improve this question
6
  • 1
    I doubt it has anything to do with the store reporting a max capacity in the exabyte range.
    – ceejayoz
    Commented Oct 28, 2016 at 19:03
  • Do you have other ideas of what it could be?
    – raphael75
    Commented Oct 28, 2016 at 19:32
  • Well, it'd help if you defined what "incredibly slow" means first.
    – ceejayoz
    Commented Oct 28, 2016 at 19:49
  • 1
    It took 10 minutes to show the file list (which was just 2 test files of about 5 bytes each), 10 minutes to open a file, 10 minutes to save a file, 10 minutes to create a folder, etc.
    – raphael75
    Commented Oct 28, 2016 at 19:57
  • 1
    You can't resize an EFS share because the 8 billion gigabytes of free space reported by EFS is not really there. It's just a number. The problem is going to be something else. Maybe this or this.
    – Michael - sqlbot
    Commented Oct 28, 2016 at 22:08

3 Answers 3

Reset to default
6

We had similar issues and found a solution for it. We were able to narrow the issue down to SAMBA failing to report EFS size in time. More specifically, samba fails to execute sys_get_nfs4_quota(), timing out in about 60 sec.

To overcome this issue, we added a custom script to samba to report 8 Exabytes instantly without trying to calculate the size. Given that this is unlimited EFS (in theory), the reported size does not matter, and returning fixed number is ok. That solves the 60 sec timeout.

To do this, create a file in /etc/samba/samba-dfree and add the two lines below:

#!/bin/bash
echo "8000000000 8000000000"

Then in the samba config file, add the following parameters to either global section, or the specific EFS mount section, depending on your needs:

dfree command = /etc/samba/samba-dfree
dfree cache time = 60

Save the config file. Restart SAMBA and the delay should go away. Hope this helps.

Improve this answer
1
  • Thank you, it works perfectly
    – imbolc
    Commented Dec 10, 2020 at 11:17
4

EFS runs on a system of IO credits, these credits are generated constantly throughout the day based on the amount of space you are using in EFS.

Every time you read or write to an EFS volume you consume these credits. If you have no IO credits in your balance, reads and writes will wait until you do.

I think it's somewhat likely, you've managed to use up all your credits, and the background IO keeps depleting your credits, keeping performance horrendous.

You can check the number of credits an EFS volume has by checking cloudwatch.

Just to clarify this a little more. If you were only using 1GiB on an EFS disk, any time you read/wrote at a rate exceeding 50KiB/s you would burn through credits, and any time you read/wrote a rate lower than 50KiB/s you would generate credits.

In comparison by having 10GiB in an EFS disk you would be able to sustain 500KiB/s.

I'm utilising EFS with one service, and found I had to generate roughly 80GiB of raw useless data, which just sits on the EFS disk to generate enough IO credits to allow my application to use the share.

I set up a cloudwatch alarm to notify me if my credits ever fall below a threshold, to give me time to add some more 'useless data' to the EFS disk to allow me to sustain usual performance.

I recommend reading Amazon's official suggestions on EFS throughput scaling if you think this effects you.

Edit: AWS now supports provisioned throughput for EFS, although that doesn't save any money from above approach and requires an understanding of expected throughput, or overestimating usage. Details of this are covered in the linked documentation.

Improve this answer
2
  • I only have 1 folder and 3 files, totaling 4,126 bytes (it was all just for testing purposes) so I wouldn't think that would be an issue. How many IO credits do you start with? Do you find the # of IO credits under the Billing Management Console?
    – raphael75
    Commented Nov 2, 2016 at 12:32
  • 1
    IO credits are shown in cloudwatch, under EFS. This isn't monetary credits, just number of IO tokens.
    – KHobbits
    Commented Nov 9, 2016 at 14:05
2

I'm having similar slow access via samba share mounted on Windows. I'm getting good performance (at least fraction of a second access when navigating directories etc) on the EC2. Windows takes minutes to become accessible from the "my computer"/"this pc" view of the mounted drives - it does seem fairly performant once i'm within the directory though.

So - is this something daft like Windows trying to figure out the size of the 8 exabyte filesystem?

Using cmd seems to support this. Enter the filesystem and run "dir" and the directories are listed followed by a long delay before the "bytes free" appears

I appreciate this is not an answer, hope it might be useful information for someone more capable than myself

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .