-----Original message-----
To: Jim Klimov <jimklimov at cos.ru>;
CC: ZFS Discussions <zfs-discuss at opensolaris.org>;
From: Carsten John <cjohn at mpi-bremen.de>
Sent: Wed 27-06-2012 08:48
Subject: Re: [zfs-discuss] snapshots slow on sol11?> -----Original message-----
> CC: ZFS Discussions <zfs-discuss at opensolaris.org>;
> From: Jim Klimov <jimklimov at cos.ru>
> Sent: Tue 26-06-2012 22:34
> Subject: Re: [zfs-discuss] snapshots slow on sol11?
> > 2012-06-26 23:57, Carsten John wrote:
> > > Hello everybody,
> > >
> > > I recently migrated a file server (NFS & Samba) from
OpenSolaris (Build
> 111)
> > to Sol11.
> > > (After?) the move we are facing random (or random looking)
outages of
> > our Samba...
> >
> > As for the timeouts, check if your tuning (i.e. the migrated files
> > like /etc/system) don''t enforce long TXG syncs (default was
30sec)
> > or something like that.
> >
> > Find some DTrace scripts to see if ZIL is intensively used during
> > these user-profile writes, and if these writes are synchronous -
> > maybe an SSD/DDR logging device might be useful for this scenario?
> >
> > Regarding the zfs-auto-snapshot, it is possible to install the old
> > scripted package from OpenSolaris onto Solaris 10 at least; I did
> > not have much experience with newer releases yet (timesliderd) so
> > can''t help better.
> >
> > HTH,
> > //Jim Klimov
> >
> > _______________________________________________
> > zfs-discuss mailing list
> > zfs-discuss at opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> >
>
>
> Hi everybody,
>
> in the meantime I was able to eliminate the snapshots. I disabled snapshot,
but
> the issue still persists. I will now check Jim''s suggestions.
>
> thx so far
>
>
> Carsten
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
We finally found the reason (thanks, wireshark). It was, in fact, not zfs nor
solaris related.
Due to a problem with a dhcp3-relay, the clients got an initial DHCP IP by
DHCPDISCOVER, but couldn''t renew their IP via DHCPREQUEST when the
maximum lease time was reached.
This resulted in a short loss of connectivity, until the client got a new IP
(actually the same as before) via DHCPDISCOVER.
The problem only showed up, if the client tried to write to the fileserver in
the period of time when the IP was lost (usually when firefox or thunderbird
tried to write to their disk cache).
thanks for the suggestions
Carsten