On Tue, 2005-03-01 at 23:17 +, David Woodhouse wrote:
On Mon, 2005-02-14 at 20:44 +, Anton Altaparmakov wrote:
So every time we get a concurrent clear_inode() and iget() for the same
inode what happens? We get your Failed to get bitmap attribute. every
time? Or can clear_inode
On Wed, 2005-03-02 at 08:43 +, Anton Altaparmakov wrote:
I thought we declared that the concurrent clear_inode() and read_inode()
were a VFS bug, and fixed it? It's even fixed in 2.4 now isn't it?
Is it? I must have missed this discussion. )-:
Wasn't that why we backported
On Thu, Oct 14, 2004 at 02:26:45PM +0100, Anton Altaparmakov wrote:
I don't like filesystem doings things like this in -put_inode at all,
and indeed the plan is to get rid of -put_inode completely. Why do
you need to hold an additional reference anyway? What's so special
about the
On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote:
If the igrab() were not done, it would be possible for clear_inode to be
called on the 'parent' inode whilst at the same time one or more attr
inodes (belonging to this 'parent') are in use and Bad Things(TM) would
happen...
On Thu, 2005-02-10 at 14:48 +, Anton Altaparmakov wrote:
On Thu, 2005-02-10 at 15:42 +0100, Christoph Hellwig wrote:
On Thu, Feb 10, 2005 at 02:40:39PM +, Anton Altaparmakov wrote:
I am not sure what you mean. The VFS layer does reference counting on
inodes. I have no choice in
On Thu, Feb 10, 2005 at 02:50:02PM +, Anton Altaparmakov wrote:
If the igrab() were not done, it would be possible for clear_inode to be
called on the 'parent' inode whilst at the same time one or more attr
inodes (belonging to this 'parent') are in use and Bad Things(TM) would
On Thu, 2005-02-10 at 15:50 +0100, Christoph Hellwig wrote:
On Thu, Feb 10, 2005 at 02:48:26PM +, Anton Altaparmakov wrote:
If the igrab() were not done, it would be possible for clear_inode to be
called on the 'parent' inode whilst at the same time one or more attr
inodes (belonging to
