xfs
[Top] [All Lists]

TAKE 964465 - Transaction delta counts are not applied atomically

To: xfs@xxxxxxxxxxx, sgi.bugs.xfs@xxxxxxxxxxxx
Subject: TAKE 964465 - Transaction delta counts are not applied atomically
From: dgc@xxxxxxx (David Chinner)
Date: Tue, 5 Jun 2007 17:40:26 +1000 (EST)
Sender: xfs-bounce@xxxxxxxxxxx
Apply transaction delta counts atomically to incore counters

With the per-cpu superblock counters, batch updates are no longer
atomic across the entire batch of changes. This is not an issue
if each individual change in teh batch is applied atomically.
Unfortunately, free block count changes are not applied atomically,
and they are applied in a manner guaranteed to cause problems.

Essentially, the free block count reservation that the transaction
took initially is returned to the in core counters before a second
delta takes away what is used. because these two operations are
not atomic, we can race with another thread that can use the
returned transaction reservation before the transaction takes
the space away again and we can then get ENOSPC being reported
in a spot where we don't have an ENOSPC condition, nor should
we ever see one there.

Fix it up by rolling the two deltas into the one so it can be
applied safely (i.e. atomically) to the incore counters.

Date:  Tue Jun  5 17:39:41 AEST 2007
Workarea:  chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs
Inspected by:  hch@xxxxxxxxxxxxx

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


Modid:  xfs-linux-melb:xfs-kern:28796a
fs/xfs/xfs_trans.c - 1.181 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h
        - Apply transaction deltas atomically by ensuring we only ever update
          each counter once per transaction.



<Prev in Thread] Current Thread [Next in Thread>
  • TAKE 964465 - Transaction delta counts are not applied atomically, David Chinner <=