, but at last the server
> won't hang for a long time.
> thanks !
Not really. Any thread ending up in ffs_copyonwrite() or ffs_snapblkfree()
will block. If this server runs NFS it could be possible that all NFS
server threads block.
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
On Wed, Apr 27, 2011 at 10:43:59AM +0200, Manuel Bouyer wrote:
> On Mon, Apr 18, 2011 at 09:36:25AM +0200, Juergen Hannken-Illjes wrote:
> > [...]
> > > Fixing 2) is trickier. To avoid the heavy writes to the snapshot file
> > > with the fs suspended, the snapshot appea
5720974 x 32768 43.4780.420
45720974 x 32768 40.7905.642
45720974 x 32768 49.700 12.748
45720974 x 32768 55.599 18.612
22860487 x 655367.0050.600
22860487 x 65536 10.5582.436
22860487 x 65536 14.3654.122
22860487 x 65536 18.615 5.739
For me snapshots
thanks for taking a look on this.
>
> ffs_fsync should not need to know if the filesystem used on its VBLK node is
> ffs or not. it should just call VFS_FSYNC as the other filesystems
> (ie. spec_fsync) do. the FSYNC_VFS flag should go away.
You mean like the
the request comes from ffs or from other file system via VFS_FSYNC().
- Take care which mount to test for WAPBL -- v_mount to update the times and
wapbl_vptomp() to update the dirty blocks. Never update times when called
by VFS_FSYNC().
Comments or objections?
--
Juergen Hannken-Illjes
summary informations (the
> second being probably a consequence of the first) appear wrong when
> running fsck against a snapshot. I believe this is fixable, but
> I've not yet found from where the information mismatch is coming from.
>
> comments ?
>
> PS: I'm away
apbl_begin().
Yes. Maybe lower the wl_dealloclim again.
> Also I wonder if it's OK for wapbl_flush() to cause more data to be
> added to the log.
It is the way wapbl works. Block deallocations produce more blocks that are
stored in the journal. Its resource estimations are fragile at le
used by
iic_smbus_send_byte() which uses "cmdlen = 0, len = 1".
So the final question: Does this change to pci/piixpm.c look ok?
Looks like alipm.c and ichsmb.c have the same problem ...
--
Juergen Hannken-Illjes -
vrele(lvp);
works but this way revoke() through a layered file system will always
inactivate and close the lower vnode so I'm not sure this is a real solution.
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
I can't recall the
> details anymore, but I remember the overflow was quite easy to trigger
> on a rump kernel. Maybe the problem triggers easier in a virtual
> environment?
... and rev 1.38 would help too.
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
n to three places, where we change page flags without holding the
object lock. With this diff (*2) in place the test runs for > 48 hours.
Using atomic ops here is not possible as flags is a 16bit value.
Any objections against the change or other ideas to solve this problem?
--
Juergen Hannken-
ot;
which may be related.
Any ideas?
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
the vnode referenced.
Any objections?
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Index: share/man/man9/namecache.9
===
RCS file: /cvsroot/src/share/man/man9/namecache.9,v
retrieving revision 1.13
On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
> The vnode lock operations currently work on a rw lock located inside the
> vnode. I propose to move this lock into the file system node.
>
> This place is more logical as we lock a file system node and not a v
On Mon, Jun 28, 2010 at 09:06:57AM +, Andrew Doran wrote:
> On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
> > The vnode lock operations currently work on a rw lock located inside the
> > vnode. I propose to move this lock into the file system node
On Sun, Jun 27, 2010 at 02:06:31AM +, David Holland wrote:
> On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
> > The vnode lock operations currently work on a rw lock located inside the
> > vnode. I propose to move this lock into the file system node.
to more than one vnode. Ptyfs allowing multiple mounts is such
a candidate.
A diff implemeting this for ufs, lfs and ext2fs is attached.
Comments or objections anyone?
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Index: sys/ufs/ufs/inode.h
On Tue, Jun 22, 2010 at 03:24:33PM +, Eduardo Horvath wrote:
> On Tue, 22 Jun 2010, Juergen Hannken-Illjes wrote:
>
> > The vnode lock operations still carry some arguments and semantics from
> > our old lockmgr(9). I propose to clean them up as:
> >
> > 1)
time I looked it were 16 calls to
vget() missing LK_INTERLOCK and two calls from vrelel() to vn_lock() with
LK_INTERLOCK set.
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
d.
A diff covering 1) and 3) is attached. The result of the substitution
's/\(VOP_UNLOCK([^,]*\), 0/\1/' to kill the second argument of
VOP_UNLOCK() is omitted as it is completely mechanic.
Comments or objections anyone?
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschw
With mount_domount() the last consumer of recursive vnode locks has left.
I propose to completely remove the concept of recursive vnode locks by
eliminating vn_setrecurse(), vn_restorerecurse() and LK_CANRECURSE.
A diff is attached.
Comments or objections anyone?
--
Juergen Hannken-Illjes
On Tue, Jun 01, 2010 at 01:54:53AM +, David Holland wrote:
> On Sun, May 23, 2010 at 04:11:25PM +0200, Juergen Hannken-Illjes wrote:
> > With our current vnode lock implementation VOP_LOCK() and VOP_UNLOCK()
> > are not symmetric. A vnode may be locked from one file system an
will remove v_vnlock and change layered file systems
to always pass the locking VOP's down to the leaf file system.
Comments or objections?
--
Juergen Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Index: sys/miscfs/genfs/layer_vn
23 matches
Mail list logo
