All of lore.kernel.org
 help / color / mirror / Atom feed
* TAKE - 964316: Dmapi get_bulkall appears to return incorrect inode information
@ 2007-09-24  0:22 Vlad Apostolov
  0 siblings, 0 replies; only message in thread
From: Vlad Apostolov @ 2007-09-24  0:22 UTC (permalink / raw)
  To: sgi.bugs.xfs; +Cc: linux-xfs

get_bulkall() could return incorrect inode state

In the following scenario xfs_bulkstat() returns incorrect
stale inode state:

1. File_A is created and its inode synced to disk.
2. File_A is unlinked and doesn't exist anymore.
3. Filesystem sync is invoked.
4. File_B is created. File_B happens to reclaim File_A's inode.
5. xfs_bulkstat() is called and detects File_B but reports the
 incorrect File_A inode state.

Explanation for the incorrect inode state is that inodes are not immediately
synced on file create for performance reasons. This leaves the on-disk inode
buffer uninitialized (or with old state from a previous generation inode)
and this is what xfs_bulkstat() would report.

The patch marks the on-disk inode buffer "dirty" on unlink. When the inode
is reclaimed (by a new file create), xfs_bulkstat() would filter this inode
by the "dirty" mark. Once the inode is flushed to disk, the on-disk buffer
"dirty" mark is automatically removed and a following xfs_bulkstat() would
return the correct inode state.

Marking the on-disk inode buffer "dirty" on unlink is achieved by 
setting the
on-disk di_nlink field to 0. Note that the in-core di_nlink has already been
set to 0 and a corresponding transaction logged by xfs_droplink().
This is an exception from the rule that any on-disk inode buffer changes
has to be followed by a disk write (inode flush).
Synchronizing the in-core to on-disk di_nlink values in advance (before the
actual inode flush to disk) should be fine in this case because the inode
is already unlinked and it would never change its di_nlink again for this
inode generation.


Date:  Mon Sep 24 10:14:37 AEST 2007
Workarea:  soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs1
Inspected by:  tes, dgc, markgw, aelder, hch@lst.de

The following file(s) were checked into:
  longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb


Modid:  xfs-linux-melb:xfs-kern:29757a
fs/xfs/xfs_itable.c - 1.155 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.155&r2=text&tr2=1.154&f=h
    - pv 964316 - get_bulkall() could return incorrect inode stat

fs/xfs/xfs_inode.c - 1.483 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.483&r2=text&tr2=1.482&f=h
    - pv 964316 - get_bulkall() could return incorrect inode stat

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-09-24  0:20 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-24  0:22 TAKE - 964316: Dmapi get_bulkall appears to return incorrect inode information Vlad Apostolov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.