Re: zfs destroy snapshot doesn't free space

[Peter Jeremy]

On 2010-Aug-13 16:51:24 +0200, Andreas Mayer  wrote:
>If I take a snapshot again, this snapshot also references 623G.
>
>What can I do to reclaim this space? I have to do this before I can
>set a quota (I have set quotas for all other file systems now :) ).

Does a reboot resolve the problem?

-- 
Peter Jeremy


pgpbzS5ldbnfc.pgp
Description: PGP signature

Re: NFS stalling on 8.1-STABLE

[Jeremy Chadwick]

On Thu, Aug 12, 2010 at 10:35:49AM -0700, Mark Morley wrote:
> I have five front end web servers that all mount their content from
> the same server via NFS.  If I stress the link on any one of the
> machines (eg: copy a large directory with a lot of files to/from the
> mounted file system) the client will pause.  That is, all processes
> trying to access that mount will freeze.  The log files with hundreds
> or thousands of nfs server not responding / is alive again messages.
> After 60 seconds it returns to normal, unless the load is still there
> in which case it continues to pause.
> 
> This has only started happening since I upgraded the client machines
> to 8.1-STABLE (previously four of them were 8.0 and one was 7.3).  The
> server is 7.1-RELEASE-p11.  No other changes have taken place in terms
> of hardware or software or mount options, etc.
> 
> All nics involved are gigabit em cards, and they are on a private
> network (web access to the boxes is via an external interface).

Are there any indications in dmesg that the NIC is responsible, e.g.
interface down/up, etc.?

Does switching to UDP-based NFS solve the problem for you?

What OS version (uname -a) and NIC are used on the NFS server?

Can you please provide the following output from one of the client
machines running 8.1-STABLE with gigE em(4)?  You can X-out machine
names, MAC addresses, and IP addresses/netblocks if need be.

* uname -a
* ifconfig emX  (where X is the interface number which would be
  used for NFS)
* netstat -idn -I emX
* pciconf -lvc  (provide only the data for emX please)
* vmstat -i
* sysctl hw.pci
* As root, run "sysctl dev.em.X.stats=1" then do "dmesg" and
  provide the output for NIC statistics (will start with "emX:")

Thanks.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Roland Smith]

On Sun, Aug 15, 2010 at 12:37:03PM -0700, Kevin Oberman wrote:
> OK. It's pretty clear that disk IO is terrible on this system. I suspect
> it's the SATA/PATA converter that is the throttle. In any case,

> I still have no explanation for the variation. It's not vibration. Some
> of my best times were while the system was sitting in my trunk while
> commuting from my home to work. So have some of the worst.

If the performance is craptastic due to the SATA/PATA convertor, could that
also not be a good explanation for the variation? With the different speeds on
the two busses, there might well be variation between the time it takes for
commands to get through (altough one would expect that to even out over time).

Of course to test that you'd have to hook up a harddisk that doesn't need the
convertor... If that improves the situation, you've found the problem.

> I can only hope that my next laptop, which should have ACHI, will improve
> the situation. I'll probably be getting a new laptop in the spring, so
> it won't be too long. Almost time to start trying to figure out what to
> buy. 

Well, looking at my laptop's figures, it is possible to get good
throughput. If you get a system with ICH9 chipset (so you can use ahci(4)),
and a 7200 RPM harddisk, and you should be able to reproduce my figures, I
think.

Roland
-- 
R.F.Smith   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)


pgppj3TD0PwJ9.pgp
Description: PGP signature

Re: NFS stalling on 8.1-STABLE

[Rick Macklem]

> Hi all,
> 
> I have five front end web servers that all mount their content from the same 
> server via NFS.  If I stress the link on any one of the machines (eg: copy a 
> large directory with a lot of files to/from the mounted file system) the 
> client will pause.  That is, all processes trying to access that mount will 
> freeze.  The log files with hundreds or thousands of nfs server not 
> responding / is alive again messages. After 60 seconds it returns to normal, 
> unless the load is still there in which case it continues to pause.
> 

The 60sec delay suggests that the client is doing a TCP reconnect. I'd suggest 
that you
look at a packet trace in wireshark (it knows how to decode NFS packets) and 
see if
there are new TCP connections (SYN, SYN-ACK,...) being made. If that is what is
happening, I suspect it is NIC driver related, but it is really hard to say.

If you can try a network interface of a different type (not em) that will check 
to
see if it is an em(4) issue.

Alternately, you could try turning off the TSO and checksum offload stuff for 
the
em(4) and see if that helps.

> This has only started happening since I upgraded the client machines to 
> 8.1-STABLE (previously four of them were 8.0 and one was 7.3).  The server is 
> 7.1-RELEASE-p11.  No other changes have taken place in terms of hardware or 
> software or mount options, etc.
> 

There were some client side fixes between 8.0 and 8.1, but I don't think any
of those have caused a regression w.r.t. connections. There is a problem w.r.t.
the nfsd getting in a loop, but that wouldn't recover after 60sec. (If it 
happens,
the server has to be rebooted. There is a fix for this at:
   http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch
but I don't think it is what you are seeing.)

rick
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Inconsistent IO performance

[Kevin Oberman]

> Date: Sun, 15 Aug 2010 00:07:40 +0200
> From: Roland Smith 
> Sender: owner-freebsd-sta...@freebsd.org
> 
> On Sat, Aug 14, 2010 at 02:36:31AM +0200, Roland Smith wrote:
> > On Fri, Aug 13, 2010 at 01:36:12PM -1000, Clifton Royston wrote:
> > > > Both figures seem quite low to me? I cannot exactly reproduce your test,
> > > > because I don't have an empty second disk handy, but doing
> > > > 
> > > > dd if=/dev/zero bs=1m count=100 of=/tmp/foo
> > >  
> > >   With a total write size of 100MB, aren't you just testing speed of
> > > writing into cache RAM this way?  I think you need to write amounts
> > > dramatically greater than the total size of the RAM to get values which
> > > appropriately measure disk speed.
> > 
> > >   This also supports that theory - off the top of my head, maximum
> > > theoretical possible write throughput to a similarly sized 7200rpm
> > > drive should be 70MB/s (buffer to disk data transfer rate according to
> > > WDC's specs.) 
> > 
> > Ok, so I tried this;
> > 
> >  dd if=/dev/zero of=/tmp/foo bs=10M count=1000
> > 
> > 1048576 bytes transferred in 138.304953 secs (75816229 bytes/sec)
> > 1048576 bytes transferred in 139.125501 secs (75369073 bytes/sec)
> > 1048576 bytes transferred in 136.149871 secs (77016305 bytes/sec)
> > 
> > Which is around 72 MiB/s with filesystem overhead, which sounds about
> > right. The drive was making plenty of noise. The point is that it is _way_
> > more than the 18-22 MiB/s on a raw disk that Kevin is getting.
> > 
> > I'll try the same on my laptop topmorrow and see what that gets me. This 
> > desktop
> > machine is ICH7 with ata(4), laptop is ICH9 with ahci(4).
> 
> Figures from the laptop running 8.1-RELEASE amd64, ahci driver with the
> following harddisk;
> 
> ada0:  ATA-8 SATA 2.x device
> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
> 
> Running the same test;
> 
> dd if=/dev/zero of=/tmp/foo bs=10M count=1000
> 
> Gives the following results.
> 
> 1048576 bytes transferred in 122.625997 secs (85510090 bytes/sec)
> 1048576 bytes transferred in 126.081170 secs (83166741 bytes/sec)
> 1048576 bytes transferred in 126.101845 secs (83153105 bytes/sec)
> 
> Which is about 10% faster than on the desktop.

OK. It's pretty clear that disk IO is terrible on this system. I suspect
it's the SATA/PATA converter that is the throttle. In any case, nothing
is going to help much when the best sequential read speed is only 34
MB/sec. I suppose something in the ATA driver may be an issue, but I
doubt it will improve.

I still have no explanation for the variation. It's not vibration. Some
of my best times were while the system was sitting in my trunk while
commuting from my home to work. So have some of the worst.

I can only hope that my next laptop, which should have ACHI, will improve
the situation. I'll probably be getting a new laptop in the spring, so
it won't be too long. Almost time to start trying to figure out what to
buy. 

Thanks to everyone who made suggestions and offered ideas.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1R: ppp default route uses wrong Netif (with pppoe)

[Luigi Rizzo]

On Thu, Aug 12, 2010 at 07:31:32PM +0400, Michael BlackHeart wrote:
> As I understand this isn't a bug but a mistype or misunderstand of config (
> see man ppp.conf )
> 
> I'm running myself 8.0, 8.1 and currently 8.STABLE with pppoe in this way
> and never have a problem as many peolpe do.
> Look in listing
> 
> > my-provider:
> > set line PPPoE:nfe0
> 
> Here's some "set line" and should be "set device" like this:

sorry it wasn't that.
I checked the source code, "set line" and "set device" are
perfect equivalent and they end up calling the same code.

cheers
luigi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"