On Tue, 30 Nov 1999, Alexander Viro wrote:
Patch merges most of block_write_{partial,cont}_page and fixes a
couple of bad bugs in the latter. It should fix the problems with
write-beyond-EOF on FAT and HPFS and it cleans the code up. [...]
looks good, but i think you have removed an
On Sat, 20 Nov 1999, Hans Reiser wrote:
place in fs/buffer.c
#ifdef CONFIG_REISERFS
#include reiserfs/buffer.c
#endif
If the user doesn't turn reiserfs on, he will take no risk at all.
I'll modify our reiserfs patch to do it that way, it should have been
done.
no, this just
On Wed, 3 Nov 1999, Stephen C. Tweedie wrote:
You can get around this problem by snapshotting the buffer cache and
writing it to the disk, of course, [...]
.. which is exactly what the RAID5 code was doing ever since. It _has_ to
do it to get 100% recovery anyway. This is one reason why
On Mon, 1 Nov 1999 [EMAIL PROTECTED] wrote:
XFS on Irix caches file data in buffers, but not in the regular buffer cache,
they are cached off the vnode and organized by logical file offset rather
than by disk block number, the memory in these buffers comes from the page
subsystem, the page
On Tue, 2 Nov 1999, Stephen C. Tweedie wrote:
i dont think dump should block. dump(8) is using the raw block device to
read fs data, which in turn uses the buffer-cache to get to the cached
state of device blocks. Nothing blocks there, i've just re-checked
fs/block_dev.c, it's using
On Fri, 29 Oct 1999, Stephen C. Tweedie wrote:
Ingo, can we work together to address this? One solution would be the
ability to mark a buffer_head as "pinned" against being written to disk,
Fixing this in raid seems far, far preferable to fixing it in the
filesystems. The filesystem
On Fri, 8 Oct 1999, Alexander Viro wrote:
yep we knew about this problem ... it's not quite an easy hack though.
Putting the directory block cache (and symlink block cache) into the page
cache would be the preferred method - this would also clean up the code
alot i think.
More or
