On 07/12/12 06:41, Colin Simpson wrote:
> I have tried the async option and that reverts to being as fast as
> previously.
>
> So I guess the choice is use the less safe async and get file creation
> being quick or live with the slow down until a potentially new protocol
> extension appears to help with this.
The most aggravating part of this is when my manager first set me the
problem of trying to find a workaround, I *did* try async, and got no
difference. Now, I can't replicate that... but the oldest version I have
is still 6.2, and I think I was working under 6.0 or 6.1.
*After* I test further, I think it's up to my manager and our users to
decide if it's worth it to go with less secure - this is a real issue,
since some of their jobs run days, and one or two weeks, on an HBS* or a
good sized cluster. (We're speaking of serious scientific computing here.)
mark
* Technical term: honkin' big server, things like 48 or 64 cores,
quarter of a terabyte of memory or so....
>
> Colin
>
>
> On Wed, 2012-07-11 at 15:16 -0700, David C. Miller wrote:
>>
>> ----- Original Message -----
>>> On Wed, Jul 11, 2012 at 11:29 AM, Colin Simpson
>>> <Colin.Simpson@xxxxxxxxxx> wrote:
>>>>
>>>> But think yourself lucky, BTRFS on Fedora 16 was much worse. This
>>>> was
>>>> the time it took me to untar a vlc tarball.
>>>>
>>>> F16 to RHEL5 - 0m 28.170s
>>>> F16 to F16 ext4 - 4m 12.450s
>>>> F16 to F16 btrfs - 14m 31.252s
>>>>
>>>> A quick test seems to say this is better in F17 (3m7.240s on BTRFS
>>>> but
>>>> still looks like we are hitting NFSv4 issues for this but btrfs
>>>> itself
>>>> is better).
>>>
>>> I wonder if the real issue is that NFSv4 waits for a directory change
>>> to sync to disk but linux wants to flush the whole disk cache before
>>> saying the sync is complete.
>>>
>>> --
>>> Les Mikesell
>>> lesmikesell@xxxxxxxxx
>>
>> I think you are right that it is the forcing of the sync operation for all writes in NFSv4 that is making it slow. I just tested on a server and client both running RHEL 6.3. I exported a directory that had an old tar.gz of open office 3.0 distribution for Linux. 175MB. Exported with the default of sync option took 26 seconds to extract from the client mount. Exported with the async option and the extraction only took 4 seconds. Just to be clear on what I tested with. This is over 1GbE. The NFS server has an Intel Core i3-2125 CPU @ 3.3GHz, 16GB ram, NFS export directory is from a 22 drive Linux RAID6 connected via a SAS 6Gb/sec HBA. The client is a Intel Core 2 duo E8400 @ 3GHz, 4GB ram.
>>
>> Mark,
>>
>> Have you tried using async in your export options yet? Any difference?
>>
>> David.
>> _______________________________________________
>> CentOS mailing list
>> CentOS@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
>
>
> ________________________________
>
>
> This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
--
"The Pluto Files", Neil Degrasse Tyson.
Pluto shall rise again! - whitroth
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
