In message <[EMAIL PROTECTED]>, Peter Jeremy write

>Whilst the solution to this appears obvious (if you can't allocate a
>block, but there are free blocks on the to-be-commited list, wait for
>free space to become available), actually implementing it is quite
>difficult if you want to avoid deadlocks.  Kirk has previously
>recommended that softupdates not be enabled on a filesystem unless it
>has sufficient free space to absorb about 1 minute's writes.

yup, this one is tricky, I tried to fix it by sleeping on the
potential of allocating a block, but even that isn't enough,
and had undesirable consequences.

>A number of people have also claimed that softupdates interacts with
>Vinum (particularly RAID-5) in undesirable ways.  I believe that at
>least some of this was a misunderstanding of the way softupdates
>handles write re-ordering (or at least the write semantics that
>softupdates expects).

This one was a misunderstanding, in fact vinum/raid5 works more
reliably with softupdates than without I belive.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]         | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to