update got lost. This is responsible for ensuring that dirty mmap() pages
get periodically written to disk. Without it, long time mmap's might not
have their dirty pages written out at all of the system crashes or isn't
cleanly shut down. This could be nasty if you've got a long-running
writing via mmap(), dirty pages used to get written to disk within 30
seconds or so.
device. But with devfs, currently, /dev/psm0 is the blocking device
and /dev/npsm0 is the non-blocking one.
DEVFS must stay consistent with the older behaviour.
PR: 6260
Reviewed by: phk
Submitted by: Kapil Chowksey <kchowksey@hss.hns.com>
- restored async mount support. The first entry in a block is still
always written synchronously, although it probably shouldn't be in
the async case.
- restored use of BWRITE() instead of bowrite() for the DOWHITEOUT
case, although bowrite() is probably better.
Broken by: merge of softdep changes (rev.1.22).
Found by: lmbench2 delete-file benchmarks.
data is greater than MLEN, setsockopt is unable to pass it onto
the protocol handler. Allocate a cluster in such case.
PR: 2575
Reviewed by: phk
Submitted by: Julian Assange proff@iq.org
is a tremendous perf decrease due to the disabling of advanced
features such as DMA, Ultra DMA, and 32bit mode. This patch
might have been reported by someone else (I seem to remember
it.)
kernal page table may need to be extended. But while growing the
kernel page table (pmap_growkernel()), newly allocated kernel page
table pages are entered into every process' page directory. For
proc0, the page directory is not allocated yet, and results in a
page fault. Eventually, the machine panics with "lockmgr: not
holding exclusive lock".
PR: 5458
Reviewed by: phk
Submitted by: Luoqi Chen <luoqi@luoqi.watermarkgroup.com>
Use config flags 0x1000 to enable LBA mode. It should be enabled in
the BIOS too to avoid geometry confusion.
One catch though, I'm not sure all BIOS's uses the 64head/63secs
translation, all mine does but....
an error if it gets a link (like it does if it gets a socket). The
implications of letting users try and do file operations on symlinks
themselves were too worrying.
(because we can :-). This means you can open a link file (or pseudo-file
in the case of short links where the data is stored in the inode rather
than disk blocks) and read the contents.
However, trap any writes from the user as it's difficult to do the right
thing in all cases. A link may be short and the user may be trying to
extend it beyond the limit and so on. Although.. being able to re-target
a symlink without deleting it first might have been nice.
This stuff is a bit perverse since symlink() and readlink() calls can
end up actually being implemented as read/write vnode ops.
Reviewed by: phk
to not follow symlinks, but to open a handle on the link itself(!).
As strange as this might sound, it has several useful applications
safe race-free ways of opening files in hostile areas (eg: /tmp, a mode
1777 /var/mail, etc). It also would allow things like fchown() to work
on the link rather than having to implement a new syscall specifically for
that task.
Reviewed by: phk
