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.simp...@iongeo.com> 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
>>> lesmikes...@gmail.com
>>
>> 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@centos.org
>> 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@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
--
"The Pluto Files", Neil Degrasse Tyson.
Pluto shall rise again! - whitroth
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
