In message <[EMAIL PROTECTED]>, Peter Jeremy write
s:
>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
