Displaying 5 results from an estimated 5 matches for "prepare_write".
2001 Oct 11
4
ext3 0.9.12 for 2.4.10-ac11
...altered so that it always calls
commit_write(), even if the copy_from_user() faulted. This change
is already present in Linus' kernel - it is a generic bugfix which
prevents leakage of stale disk data in rare circumstances.
lo_send() has also been changed so that it too calls commit_write()
if prepare_write() succeeded.
The net result is that all prepare_write()/commit_write() calls
are now balanced, so the abort_write() a_op (which was introduced
to cope with the perpare-but-no-commit error case) has been
removed.
This is an internal kernel API change! All callers of prepare_write()
must now call...
2003 Sep 22
3
journal buffer_credits problem
Hi, we're working on a stackable versioning file system for 2.4.x.
Versioning can easily create lots of files for a file that gets modified
frequently, and our current design puts all versions of a file in the same
directory as the main file. We are therefore evaluating how stable and
efficient different combinations of file systems would be in this scenario.
We've run our versionfs on
2001 Oct 10
1
ordered data
...data writes.
Suppose we (i.e. intermezzo) does a transaction, which is closed and
then followed by an ordered write. Let's assume the ordered write
doesn't require new allocation metadata.
Is the write still postponed until the first transaction has
committed?
As far as I can see, prepare_write always starts a transaction, but
I'm not sure that this ultimately results in an ordering constraint.
- Peter -
2001 Sep 24
1
ext3-2.4-0.9.10
...ream kernel.
Changelog:
- Fix an oops which could occur at unmount time due to non-empty
orphan list. This could be triggered by an earlier error during a
truncate.
- Merge Ted's directory scan speedup heuristic.
- Remove the abort_write() address_space_operation by ensuring that
all prepare_write() callers always call commit_write().
- A number of changes to suit the new 2.4.10 VM and buffer-layer design.
-
2002 Sep 22
2
Assertion failure in ext3_get_block() at inode.c:853: "handle != 0"
Hi,
Got the following on Linux 2.5.37 trying to run apt-get update.
MikaL
Sep 21 23:10:05 devil kernel: Assertion failure in ext3_get_block() at inode.c:853: "handle != 0"
Sep 21 23:10:05 devil kernel: kernel BUG at inode.c:853!
Sep 21 23:10:05 devil kernel: invalid operand: 0000
Sep 21 23:10:05 devil kernel: CPU: 1
Sep 21 23:10:05 devil kernel: EIP: