knew what it was supposed to be used for and wrstuden gave a go-ahead
* while rototilling, convert file systems which went easily to
use VFS_PROTOS() instead of manually prototyping the methods
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.
* panic if flushing system nodes fails: we have released too many
resources and would die anyway the next time unmount is attempted
* KASSERT that VOP_CLOSE succeeds, but always return 0. once again
we have released too many resources
XXX: maybe rewrite to be a bit more robust
- Raise an error if renaming a file to a directory.
- Raise an error if renaming a directory to a file.
- Raise an error if renaming a directory to a non-empty directory.
- Properly allow renaming a directory to an empty directory.
The system could previously crash if the kernel had DIAGNOSTIC enabled,
as this triggered a bogus assertion.
Problem found by Geoff Wing.
it has supplied us). If we fault pages which are at offset >= server
size, but less than the in-kernel vnode size, inform the file server
of the latest developments in file size before issueing the fault.
The avoids confusion with files which are not written start to finish.
fixes kern/36429 by yamt
the file server inactive less over-eagerly executed and masks some
problems with the new mounting style. Effectively, it makes some
file systems such as psshfs mountable again (only without -o allops).
fs code is a kernel buffer, pass though the length of the buffer as well.
Since the length of the userspace buffer isn'it (yet) passed through the mount
system call, add a field to the vfsops structure containing the default length.
Split sys_mount() for calls from compat code.
Ride one of the recent kernel version changes - old fs LKMs will load, but
sys_mount() will reject any attempt to use them.
1) Comply with the way buffercache(9) is intended to be used. Now we
read in single blocks of EFS_BB_SIZE, never taking in variable
length extents with a single bread() call.
2) Handle symlinks with more than one extent. There's no reason for
this to ever happen, but it's handled now.
3) Finally, add a hint to our iteration initialiser so we can start
from the desired offset, rather than naively looping through from
the beginning each time. Since we can binary search the correct
location quickly, this improves large sequential reads by about
40% with 128MB files. Improvement should increase with file size.
When reading a file, we would erroneously iterate to the next extent
before having filled the entire uio request. This lead to unnecessary
extent iteration and excessive calls to efs_read.
Sequential read performance has doubled in the uncached case and
quadrupled when data is buffered.
rumble