Hans Reiser [EMAIL PROTECTED] writes:
I feel we should encourage Linus to allow the following:
* unions in struct buffer_head and struct page containing filesystem specific
fields comparable to the union in struct inode.
No.
In struct buffer_head I don't have problems.
In struct page
I began screwing around the truncate() stuff and the following is
a status report/request for comments:
a) call of -truncate() method (and vmtruncate()) had been moved
into the notify_change(). It is triggered if ATTR_SIZE is set. Modified
places: do_truncate(), nfsd_truncate(),
hpfs - no problems, but there is something rather odd. Why on the
Earth does it forcibly write inode to disk in the end of notify_change()?
Immediately before that inode is dirtified by inode_setattr(). Mikulas, is
there something special that makes you write it ASAP?
HPFS doesn't use
On Mon, 11 Oct 1999, Mikulas Patocka wrote:
I mean the following: assume that call of hpfs_truncate() (via
-truncate()) had been moved into the inode_setattr() (i.e. happens
immediately before the hpfs_write_inode() in hpfs_notify_change()). Will
it have any bad consequences? Right now
"Stephen C. Tweedie" [EMAIL PROTECTED] writes:
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will
On Mon, 11 Oct 1999, Stephen C. Tweedie wrote:
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will
Hi,
On Sun, 10 Oct 1999 16:57:18 +0200 (CEST), Andrea Arcangeli
[EMAIL PROTECTED] said:
My point was that even being forced to do a lookup before creating
each empty buffer, will be still faster than 2.2.x as in 2.3.x the hash
will contain only metadata. Less elements means faster lookups.
