initialized, causing those functions to read|write a random amount.
* This fixes bug #1614 - amazing how well the system worked with those randomly
sized requests...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22901 a95241bf-73f2-0310-859d-f6bbb57e9c96
honoured (in the Inode attribute code), it also couldn't be honoured there.
Therefore, the locking order is now reversed, that is "journal" comes first,
then the Inode write lock. This should also help with the lock ups that
appeared after r22886.
* Got rid of INODE_NO_TRANSACTION; it doesn't make any sense to use.
* When Inode::WriteAttribute() changed the type, the type field was actually
never written back within the current transaction.
* If the attribute data fit into the inode again, the attribute's write lock
was never released.
* Since r22886, Inode::ReadAt() does its own locking, so we must no longer lock
the inode before calling it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22897 a95241bf-73f2-0310-859d-f6bbb57e9c96
defined in the headers. If this is not the correct way to do this, let me
know, but it seems to work (well it compiled at least.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22890 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fix the problem with duplicated parent partition entries, we need to recurse
into child rows when findig a particular BRow, or else RowAt() or CountRows()
will only return the top level list entries
* disabled the bitmap column for now, to get a better overview of "level"
* display the device path also for partitions, not just devices
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22889 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
* Don't generate an uninitialize job, when there's the partition wasn't
initialized anyway (the syscall would fail in this case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22883 a95241bf-73f2-0310-859d-f6bbb57e9c96
system by pretty name (not only module name) now.
* _user_initialize_partition() loads the disk system by pretty name.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22880 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rewrote _AllocateEndpoint
* More work in the constructor
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22873 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file. Added function to check the volume name.
* Removed bfs_validate_initialize(). This functionality is to be implemented
in a userland add-on.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22871 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems, and possibly enable ports 7 and 8 in the future.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22869 a95241bf-73f2-0310-859d-f6bbb57e9c96
The Jmicron AHCI controller has a mode that combines IDE and AHCI functionality
into a single PCI device at function 0. This happens when the controller is set
in the BIOS to "basic" or "IDE" mode (but not in "RAID" or "AHCI" mode).
To avoid needing two drivers to handle a single PCI device, we switch to the
multifunction (split device) AHCI mode. This will set PCI device at function 0
to AHCI, and PCI device at function 1 to IDE controller.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22868 a95241bf-73f2-0310-859d-f6bbb57e9c96
did not propagate the "dontWait" argument, letting the page writer never wait
for its pages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22860 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
* add partition creation menu items
* filter filesystems by their support for "initializing"
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22855 a95241bf-73f2-0310-859d-f6bbb57e9c96
