using it.
* IOW cache_prefetch_vnode() should work again now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26468 a95241bf-73f2-0310-859d-f6bbb57e9c96
per cache.
* Changed the strategy vm_cache_acquire_page_cache_ref() uses to ensure
that the cache isn't deleted while trying to get a reference. Instead
of the global cache pages hash table lock, it holds the global cache
list lock now. We acquire + release this lock in delete_cache() after
removing all pages and just before deleting the object.
* Some small optimizations using the property that the cache's pages are
ordered, now (vm_cache_resize(), vm_page_write_modified_page_range(),
vm_page_schedule_write_page_range()).
* Replaced some code counting a cache's pages by simply using
vm_cache::page_count.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26160 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Trivial adjustments of code using mutexes. Mostly removing the
mutex_init() return value check.
* Added mutex_lock_threads_locked(), which is called with the threads
spinlock being held. The spinlock is released while waiting, of
course. This function is useful in cases where the existence of the
mutex object is ensured by holding the threads spinlock.
* Changed the two instances in the VFS code where an IO context of
another team needs to be locked to use mutex_lock_threads_locked().
Before it required a semaphore-based mutex implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25283 a95241bf-73f2-0310-859d-f6bbb57e9c96
respective Private* base class.
* Changed sigwait() and sigsuspend() to use thread_block() instead of a
condition variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25100 a95241bf-73f2-0310-859d-f6bbb57e9c96
file system to not fill newly created space with zeros.
BFile::SetSize() now uses this, while [f]truncate() does not. This
is only a temporary work-around until BFS supports sparse files.
* Apps that want to reserve space to fill up later should use
BFile::SetSize() for now, as this will be a lot faster than
[f]truncate().
* cache_io() and the functions below now use a special mode when you
pass in a NULL buffer: for read access, the cache is only populated
(useful for prefetching), for write access, the file is filled with
zeros.
* Implemented BFS's Inode::FillGapWithZeros() using this method now.
* Removed extraneous white space.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24555 a95241bf-73f2-0310-859d-f6bbb57e9c96
that can be used by file systems.
* Changed the way the file cache works: instead of reading/writing to the
underlying device directly, it can now be used for any data source, ie.
also network file systems.
* As a result, the former pages_io() moved to the VFS layer, and can now be
called by a file system via {read|write}_file_io_vec_pages() (naming
suggestions are always welcomed :-)). It now gets an FD, and uses that to
communicate with the device (via its fs_{read|write}_pages() hooks).
* The file_cache_{read|write}() functions must now be called without holding
an I/O relevant file system lock. That allows the file cache to prepare the
pages without colliding with the page writer, IOW the "mayBlock" flag can
go into the attic again (yay!).
* This also results in a much better performance when the system does I/O and
is low on memory, as the page writer can now finally write back some pages,
and that even without maxing out the CPU :)
* The API changes put slightly more burden on the fs_{read|write}_pages()
hooks, but in combination with the file_map it's still pretty straight
forward. It just will have to dispatch the call to the underlying device
directly, usually it will just call its fs_{read|write}_pages() hooks
via the above mentioned calls.
* Ported BFS and FAT to the new API, the latter has not been tested, though.
* Also ported the API changes to the fs_shell. I also completely removed its
file cache level page handling - the downside is that device access is no
longer cached (ie. depends on the host OS now), the upside is that the code
is greatly simplified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22886 a95241bf-73f2-0310-859d-f6bbb57e9c96
and write_to_cache() before, IOW the cache could reserve too few pages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22859 a95241bf-73f2-0310-859d-f6bbb57e9c96
needed pages correctly, and would also not read/write enough in case the
offset didn't start at 0 resulting in undetected short reads/writes. It's
amazing how many bugs can be hidden in a few lines of code.
* Fixed a bug that might have been the cause for bug #1601: when the last part
of the write did not end on a page boundary, the last page had to be read
first, but that was done from the wrong offset. Also, if only parts of that
page could be read (because the file size didn't span over the whole page)
the remaining parts needed to be cleared.
* The cache_funcs were always called with the same value for numBytes and
bufferSize so I've eliminated the former.
* Large reads now also bypass the cache in case of low memory, large writes now
also only bypass the cache in that case, following Ingo's suggestion.
* Fixed compilation with debugging turned on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22858 a95241bf-73f2-0310-859d-f6bbb57e9c96
than 64KB. Reads should probably get a similar logic, at least if memory is
tight.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22857 a95241bf-73f2-0310-859d-f6bbb57e9c96
sequential access.
* This is now used to let the cache free some pages (or schedule them to be
written back) before vm_reserve_pages() is called, but only if that cache
is not mapped, and there is a memory shortage.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22731 a95241bf-73f2-0310-859d-f6bbb57e9c96
pages to reserve, which could result in to few being reserved in certain
situations.
* Use MutexLocker where appropriate.
* Reordered includes following the new rules.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22494 a95241bf-73f2-0310-859d-f6bbb57e9c96
busy vnodes.
* dir_create_entry_ref() used get_vnode() incorrectly (and could therefore
potentially prevent a file system from doing proper locking when called
from the kernel).
* The vnode_store now uses this for its acquire_unreferenced_ref()
implementation (and therefore for the page writer).
* read_into_cache() and write_to_cache() were still marked inline.
* The system will now wait 10 secs for a busy vnode before returning an error.
* It will also no longer panic in that case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22485 a95241bf-73f2-0310-859d-f6bbb57e9c96
allocate with the vm_cache locked - this is necessary to be able to steal pages
from itself (large files...).
The system doesn't actually lock up anymore, but it still renders itself unusable;
obviously the page thief does not work correctly, yet. The rest of the experience
is created by our current scheduler (the page thief runs and runs, but it doesn't
free any pages anymore).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22466 a95241bf-73f2-0310-859d-f6bbb57e9c96
twice into the same cache: cache_io() called read_into_cache() (or
write_to_cache()), and that broke down the request into smaller parts.
It then called read_chunk_into_cache() (or write_chunk_to_cache() resp.)
to actually allocate pages and fulfill the request.
However, it needed to unlock the cache for each chunk, and in the mean
time someone else could insert pages into the remaining chunks.
* Now, cache_io() already takes care of chunking the data which makes this
approach safe, and also simplified the code a bit - read_into_cache()/
write_to_cache() are gone now. I've renamed read_chunk_into_cache() to
read_into_cache() (same for the write function).
* Also got rid of that goto in that function while I was on it.
* Disabled cache_prefetch_vnode() for now (it's similar to cache_io(), but
since it's currently not used [since no cache module is installed yet],
I didn't want to go through updating it now, too).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22465 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the page writer don't allow to block, while all other writers do. This fixes
bug #1509. The reason the page writer needs this is because it marks several
pages from different caches as busy.
* Fixed a warning about ASSERT being defined already in BFS, since
util/DoublyLinkedList.h now includes debug.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22434 a95241bf-73f2-0310-859d-f6bbb57e9c96
is tracked while the page scanner runs much slower. Now, we just set it to a
fixed positive, so that they can easily age in case they are actually unused.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22320 a95241bf-73f2-0310-859d-f6bbb57e9c96
are locked, there is now a vm_page_reserve_pages() call to ensure upfront that
there is a page for me when I need it, and may have locked some caches.
* The vm_soft_fault() routine now makes use of that feature.
* vm_page_allocate_page() now resets the vm_page::usage_count, so that the file
cache does not need to do this in read_chunk_into_cache() and
write_chunk_to_cache().
* In cache_io() however, it need to update the usage_count - and it does that
now. Since non-mapped caches don't have mappings, the page scanner will punish
the cache pages stronger than other pages which is accidently just what we
want.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22319 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed the vm_cache/vm_store ref_count duality that besides being a bit ugly
also created the page dameon cache retrieval problem: now, only areas (and
cache consumers) retrieve a reference to the store (and therefore, the vnode).
The page daemon doesn't need to care about this at all anymore, and the pseudo
references of the vm_cache could be removed again.
* Rearranged deletion of vnodes such that its ID can be reused directly after
fs_remove_vnode() has been called.
* vm_page_allocate_page() no longer panics when it runs out of pages, but just
waits for new pages to become available using the new sFreeCondition condition
variable - to make sure this happens in an acceptable time frame, it'll
trigger a run of the low memory handlers.
* Implemented a page_thief() that steals inactive pages from caches and puts
them into the free queue. It runs as a low memory handler.
* The file cache now sets the usage count on the pages it inserts into the
cache (needs some rework though, cache_io() doesn't do it yet).
* Instead of panicking, the kernel will currently dead lock in low memory
situations, since BFS does a bit too much in bfs_release_vnode().
* Some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22315 a95241bf-73f2-0310-859d-f6bbb57e9c96
correct values (resolving a TODO); however, the latter doesn't do anything
with those yet.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22154 a95241bf-73f2-0310-859d-f6bbb57e9c96
since fault_find_page() does no longer insert a dummy page into a cache
that has a store from which it can read the page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21887 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed a few instances where the page state was set busy directly after
allocating it. This is a no-op, since a page is always busy after
allocation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21875 a95241bf-73f2-0310-859d-f6bbb57e9c96
removed in several cases.
* vfs_get_vnode_cache() now always gives out a reference to the cache it
returns; if it needs to allocate a new one, the vnode owns one reference,
and the caller another.
* therefore, file_cache_create() now owns a reference to its vm_cache_ref, and
frees it in file_cache_delete().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21533 a95241bf-73f2-0310-859d-f6bbb57e9c96
small to hold the information for the requested I/O size.
* get_file_map() returned B_BUFFER_OVERFLOW already in case the array
was exactly as large as needed.
* read_chunk_into_cache() and write_chunk_to_cache() will no longer
override their local "size" variable.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20509 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a few comments.
* Simplified the nested while loops by dropping the special handling for the
first iovec and restructuring the innermost loop. This also rules out
the possibility of a zero-length temporary vec. IMHO the readability
has improved quite a bit (YMMV :-). Hopefully without introducing new
bugs; please review!
* Corrected computation of totalSize in case less than size has been
read/written.
* Also set *_numBytes in case all fileVecs have been processed. Only
relevant in case the request extends beyond the end of file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20483 a95241bf-73f2-0310-859d-f6bbb57e9c96
filling them which could have written over the stack, and their iovec length
was set for the wrong iovec, potentially clobbering any memory.
* The first tempVec was usually empty, anyway, as the wrong iovec was chosen
to start from (usually one too early).
* The tempVec loop is now repeated until the whole fileVec is completed.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20476 a95241bf-73f2-0310-859d-f6bbb57e9c96
will now grab a reference to the vnode as well if successful. This way, vfs_get_vnode_cache()
now actually works how it should: it will now always grab a reference to the cache and
its underlying vnode. This removes an extra reference to the vnode (and vm_cache) that
got ignored before and prevented volumes to be unmounted (or file caches to be removed).
Thanks to Korli for pointing this out.
* file_cache_create() is now aware of that extra vnode reference and releases it; unmounting
volumes is now working again as it should.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18716 a95241bf-73f2-0310-859d-f6bbb57e9c96
into more than MAX_FILE_IO_VECS pieces. This could have very weird consequences
like overwriting data outside the file (but on that same partition only).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17536 a95241bf-73f2-0310-859d-f6bbb57e9c96
reading the file map of certain files (hope I got that more or less
right)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17525 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems a chance to know if they have locked already.
This fixes a locking problem in BFS where one thread tried to acquire two read
locks (where someone else trying to acquire a write lock would have caused a
dead lock).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17108 a95241bf-73f2-0310-859d-f6bbb57e9c96
since it unlocked the cache while waiting on a busy page. Now, we're filling
the pending request before unlocking the cache.
* Fixed the deadlock I mentioned in the last commit: if a page fault happens
at the same time we're trying to read/write from/to a page, we no longer
fight for the BFS inode lock, but eventually doing the job twice if needed.
Will need to go over the "write modified" functions to make sure they are
behaving as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17091 a95241bf-73f2-0310-859d-f6bbb57e9c96
vm_cache_ref starts with a reference count of 1. When acquiring a vm_cache,
you no longer need to worry if that should go through the vm_store, or not;
as it now always does.
* map_backing_store() no longer needs to play with the vm_cache_ref
references.
* that simplified some code.
* vfs_get_vnode_cache() now grabs a reference to the cache, if successful.
* better balanced vnode ownership on vnode_store creation (vnode_store
released the vnode before if its creation failed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15641 a95241bf-73f2-0310-859d-f6bbb57e9c96
this saves 4 bytes per page. To compensate the loss of bytes, the offset is now
stored in page size units, that's enough to address 2^44 or 16 TB (which is now
the maximal supported file size!).
* Renamed vm_page::ppn to physical_page_number.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15637 a95241bf-73f2-0310-859d-f6bbb57e9c96
will no longer panic, but free its allocated pages.
I ran into this because BFS managed to create a file without data stream but
with a length larger than 0...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15093 a95241bf-73f2-0310-859d-f6bbb57e9c96
about our block_io module not honouring the total length in read_pages().
Removed drops into the debugger when there is a block without an "original"
data buffer - that's completely normal and happens when someone asks for
a cleared block that is not yet in the cache.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14437 a95241bf-73f2-0310-859d-f6bbb57e9c96
to it - if that page was read from disk unmodified before (or written back in
the mean time), the updated contents coult not be detected, and therefore, were
never written back.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14048 a95241bf-73f2-0310-859d-f6bbb57e9c96
was incorrectly calculated, and could therefore cause all sorts of troubles with
writes over 4 kB.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14011 a95241bf-73f2-0310-859d-f6bbb57e9c96
only a read lock on the inode, or without a lock at all (in case of prefetching) - it
is now using the cache_ref's lock to make sure it's retrieved only once and doesn't
waste/corrupts any memory.
- since that fix made it mandatory to fix write_chunk_into_cache() to not call pages_io()
while holding the cache_ref's lock (was a to-do item before), I changed it to make
that possible.
- It now also supports write-through caches in theory - as there is no way yet to tell
a cache to work this way.
- Optimized for the not so uncommon case of writing the last part of a file that is not
a multiple of the page size - it won't call pages_io() anymore then, but zero the rest
of the page directly.
- vm_page_write_modified() is now calling write_page() without holding the cache_ref's
lock as well.
The updated write_chunk_to_cache() is not so well tested, though, but appears to work
so far.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14006 a95241bf-73f2-0310-859d-f6bbb57e9c96
Axel Dörfler