On Thu, Sep 30, 2010 at 1:33 AM, Simon Andrews
wrote:
> On 29/09/2010 20:09, JB wrote:
>>> Thanks.
>>> Could you please give us (on Fedora 13) an unedited output of:
>> # cat /etc/mtab
>> # cat /proc/mounts
>
> remote.server.name:/vol/ftp/ftp-1 /mnt/remote nfs
> rw,relatime,vers=3,rsize=65536,wsiz
On Wed, Sep 29, 2010 at 8:27 AM, Ian Chapman
wrote:
> On 29/09/10 22:51, Simon Andrews wrote:
>
>> That sounds like it might be an answer. It's a shame there's no way to
>> specify this per-process, but this machine does have quite a bit of RAM
>> in it, so having this specified as a percentage o
JB gmail.com> writes:
> ...
Firewall impact.
See 'man 5 nfs' - Mounting through a firewall.
Because you do not have access to your nfs server, the nfs client remains to
be checked for any messages coming from nfs server that may be blocked or
perhaps erroneously forwarded by your Fedora 13 cli
On 30/09/2010 01:21, Wolfgang S. Rupprecht wrote:
>
> Simon Andrews writes:
>> Does anyone know how to either make this buffer smaller, or get rid of
>> it all together so the scp can accruately report on its progress?
>
> Why not cut to the chase and run scp to the remote server. TCP will do
> a
On 29/09/2010 20:09, JB wrote:
>> Thanks.
>> Could you please give us (on Fedora 13) an unedited output of:
> # cat /etc/mtab
> # cat /proc/mounts
remote.server.name:/vol/ftp/ftp-1 /mnt/remote nfs
rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mou
On 29/09/2010 16:27, Ian Chapman wrote:
> On 29/09/10 22:51, Simon Andrews wrote:
>
>> That sounds like it might be an answer. It's a shame there's no way to
>> specify this per-process, but this machine does have quite a bit of RAM
>> in it, so having this specified as a percentage of RAM might m
JB gmail.com> writes:
> ...
How nfsiod's number of read-ahead/write-behind worker threads is determined
and configured ?
$ cat linux-2.6.34.i686/fs/nfs/internal.h
/*
* NFS internal definitions
*/
...
/* Maximum number of readahead requests
* FIXME: this should really be a sysctl so that user
JB gmail.com> writes:
> ...
There are other things to consider.
$ man 5 exports
...
/etc/exports
...
General Options
...
async ...
sync ...
$ man 5 nfs
...
/etc/fstab
...
Valid options for either the nfs or nfs4 file system type
...
wsize=nThe m
On Wed, 29 Sep 2010 17:21:25 -0700
Wolfgang S. Rupprecht wrote:
> Why not cut to the chase and run scp to the remote server. TCP will do
> a wonderful job of filling your pipe, but not too much.
I see long delays with scp between two different systems talking
to ext3 filesystems on both ends. Th
Simon Andrews writes:
> Does anyone know how to either make this buffer smaller, or get rid of
> it all together so the scp can accruately report on its progress?
Why not cut to the chase and run scp to the remote server. TCP will do
a wonderful job of filling your pipe, but not too much.
-wo
On 09/28/2010 07:07 AM, Simon Andrews wrote:
> Does anyone know how to either make this buffer smaller, or get rid of
> it all together so the scp can accruately report on its progress?
Mount the NFS filesystem with the "sync" option.
--
users mailing list
users@lists.fedoraproject.org
To unsubsc
JB gmail.com> writes:
>
> Simon Andrews bbsrc.ac.uk> writes:
>
> > ...
> > I think it must be part of the kernel. There's no nfsiod binary
> > anywhere on the system, but:
> >
> > $ ps aux | grep -i nfsiod
> > root 8974 0.0 0.0 0 0 ? S Sep27 0:15 [nfsiod]
> >
> > Where the parent
> YOU CANNOT!!! IT IS DONE BY THE KERNEL!!! AND IT IS SET IN CONCRETE!!
> READ MY SUBSEQUENT REPLY AS WELL.
Your capslock key appears to have failed.
Alan
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/l
Simon Andrews bbsrc.ac.uk> writes:
> ...
> >
> >> It looks like the nfs daemon is caching write data (around 2GB of it)
> >> which lets scp think its finished when actually there's loads of data
> >> sitting in a write buffer. The hanging is presumably the time it takes
> >> to flush the buffer
d of the link I'm operating over.
YOU CANNOT!!! IT IS DONE BY THE KERNEL!!! AND IT IS SET IN CONCRETE!!
READ MY SUBSEQUENT REPLY AS WELL.
>
>> In the case of nfs, buffering is done by the nfsiod.
>> Buffering will be done at both the server AND the client.
>> This is especially n
Simon Andrews bbsrc.ac.uk> writes:
> ...
> I think it must be part of the kernel. There's no nfsiod binary
> anywhere on the system, but:
>
> $ ps aux | grep -i nfsiod
> root 8974 0.0 0.0 0 0 ? S Sep27 0:15 [nfsiod]
>
> Where the parent process is kthread.
>
> Simon.
Thanks.
Could
On 29/09/10 22:51, Simon Andrews wrote:
> That sounds like it might be an answer. It's a shame there's no way to
> specify this per-process, but this machine does have quite a bit of RAM
> in it, so having this specified as a percentage of RAM might make it
> larger than we'd want.
>
> I'll have
On 29/09/2010 14:12, Ian Chapman wrote:
> On 28/09/10 22:07, Simon Andrews wrote:
>
>> Does anyone know how to either make this buffer smaller, or get rid of
>> it all together so the scp can accruately report on its progress?
>
> You could try adjusting /proc/sys/vm/dirty_ratio.
>
> "Contains, as
On 29/09/2010 12:19, JB wrote:
> Simon Andrews bbsrc.ac.uk> writes:
>
>> ...
>
> Hi,
> thanks.
>
>> It looks like the nfs daemon is caching write data (around 2GB of it)
>> which lets scp think its finished when actually there's loads of data
>> sitting in a write buffer. The hanging is presumab
On 28/09/10 22:07, Simon Andrews wrote:
> Does anyone know how to either make this buffer smaller, or get rid of
> it all together so the scp can accruately report on its progress?
You could try adjusting /proc/sys/vm/dirty_ratio.
"Contains, as a percentage of total system memory, the number of
Simon Andrews bbsrc.ac.uk> writes:
> ...
Hi,
thanks.
> It looks like the nfs daemon is caching write data (around 2GB of it)
> which lets scp think its finished when actually there's loads of data
> sitting in a write buffer. The hanging is presumably the time it takes
> to flush the buffe
On 29/09/2010 09:55, JB wrote:
> Simon Andrews bbsrc.ac.uk> writes:
> Hi Simon,
>
> you know, we are Linux users from Missouri USA here ...
> Can you tell us what system your nfs server is installed on, how its exported
> nfs shares are configured ?
> Then we can gain some valuable clues regardin
I think I get the general process by which the caching happens, and I'm
not necessarily aiming to get rid of it, just set the cache size to
something which is appropriate for the speed of the link I'm operating over.
> In the case of nfs, buffering is done by the nfsiod.
>
Simon Andrews bbsrc.ac.uk> writes:
>
> I have a fedora 13 box on which I have a remote mounted nfs share over a
> fairly slow (10Mb/s) link. I'm then transferring data onto this share
> from a different machine using scp.
>
> The problem is that after scp reports that it's 100% complete the
On 09/28/2010 06:26 PM, Samuel Kidman wrote:
>
>
> On Tue, Sep 28, 2010 at 10:07 PM, Simon Andrews
> mailto:simon.andr...@bbsrc.ac.uk>> wrote:
>
> I have a fedora 13 box on which I have a remote mounted nfs share
> over a
> fairly slow (10Mb/s) link. I'm then transferring data onto t
t; Simon.
>
Hey! Simon,
Listen: buffering is done by the filesystem internals
in collaboration with the block io layer. Once the filesystem
commits the write to block io layer, the write call returns to
the calling program, and there is not an iota you can do about
it! In the case of nfs,
On Tue, Sep 28, 2010 at 10:07 PM, Simon Andrews
wrote:
> I have a fedora 13 box on which I have a remote mounted nfs share over a
> fairly slow (10Mb/s) link. I'm then transferring data onto this share
> from a different machine using scp.
>
> The problem is that after scp reports that it's 100%
On 09/28/2010 11:58 AM, Kwan Lowe wrote:
> On Tue, Sep 28, 2010 at 1:39 PM, JD wrote:
>
>> At 90%, the transfer time comes down to 31 minutes.
>>
>> So, 20 minutes is absolutely miraculous!!!
>> Be HAPPY!!
> Could be compression on the SCP link..
Hmm... doubtful!
--
users mailing list
u
On Tue, Sep 28, 2010 at 1:39 PM, JD wrote:
> At 90%, the transfer time comes down to 31 minutes.
>
> So, 20 minutes is absolutely miraculous!!!
> Be HAPPY!!
Could be compression on the SCP link...
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
On 09/28/2010 07:07 AM, Simon Andrews wrote:
> I have a fedora 13 box on which I have a remote mounted nfs share over a
> fairly slow (10Mb/s) link. I'm then transferring data onto this share
> from a different machine using scp.
>
> The problem is that after scp reports that it's 100% complete
On Tue, 28 Sep 2010 15:07:25 +0100
Simon Andrews wrote:
> Does anyone know how to either make this buffer smaller, or get rid of
> it all together so the scp can accruately report on its progress?
I don't know how to fix it, but I don't think it has anything to
do with NFS. I see the same with e
I have a fedora 13 box on which I have a remote mounted nfs share over a
fairly slow (10Mb/s) link. I'm then transferring data onto this share
from a different machine using scp.
The problem is that after scp reports that it's 100% complete the
program will hang for ~20 mins before it will mov
32 matches
Mail list logo
