All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: di_flushiter considered harmful
Date: Mon, 22 Jul 2013 13:07:32 +0200	[thread overview]
Message-ID: <20130722110732.GA365@x4> (raw)
In-Reply-To: <1374488304-13044-1-git-send-email-david@fromorbit.com>

On 2013.07.22 at 20:18 +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> When we made all inode updates transactional, we no longer needed
> the log recovery detection for inodes being newer on disk than the
> transaction being replayed - it was redundant as replay of the log
> would always result in the latest version of the inode woul dbe on
> disk. It was redundant, but left in place because it wasn't
> considered to be a problem.
> 
> However, with the new "don't read inodes on create" optimisation,
> flushiter has come back to bite us. Essentially, the optimisation
> made always initialises flushiter to zero in the create transaction,
> and so if we then crash and run recovery and the inode already on
> disk has a non-zero flushiter it will skip recovery of that inode.
> As a result, log recovery does the wrong thing and we end up with a
> corrupt filesystem.
> 
> Because we have to support old kernel to new kernl upgrades, we
> can't just get rid of the flushiter support in log recovery as we
> might be upgrading from a kernel that doesn't have fully transaction
> inode updates.  Unfortunately, for v4 superblocks there is no way to
> guarantee that log recovery knows about this fact.
> 
> We cannot add a new inode format flag to say it's a "special inode
> create" because it won't be understood by older kernels and so
> recovery could do the wrong thing on downgrade. We cannot specially
> detect the combination of zero mode/non-zero flushiter on disk to
> non-zero mode, zero flushiter in the log item during recovery
> because wrapping of the flushiter can result in false detection.
> 
> Hence that makes this "don't use flushiter" optimisation limited to
> a disk format that guarantees that we don't need it. And that means
> the only fix here is to limit the "no read IO on create"
> optimisation to version 5 superblocks....

I think your patch misses the following part:

@@ -1054,17 +1056,15 @@ xfs_iread(
 
        /* shortcut IO on inode allocation if possible */
        if ((iget_flags & XFS_IGET_CREATE) &&
-           !(mp->m_flags & XFS_MOUNT_IKEEP)) {
+           !(mp->m_flags & XFS_MOUNT_IKEEP) &&
+           xfs_sb_version_hascrc(&mp->m_sb)) {
                /* initialise the on-disk inode core */
                memset(&ip->i_d, 0, sizeof(ip->i_d));
                ip->i_d.di_magic = XFS_DINODE_MAGIC;
                ip->i_d.di_gen = prandom_u32();
-               if (xfs_sb_version_hascrc(&mp->m_sb)) {
-                       ip->i_d.di_version = 3;
-                       ip->i_d.di_ino = ip->i_ino;
-                       uuid_copy(&ip->i_d.di_uuid, &mp->m_sb.sb_uuid);
-               } else
-                       ip->i_d.di_version = 2;
+               ip->i_d.di_version = 3;
+               ip->i_d.di_ino = ip->i_ino;
+               uuid_copy(&ip->i_d.di_uuid, &mp->m_sb.sb_uuid);
                return 0;
        }
 


-- 
Markus

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-07-22 11:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 10:18 [PATCH] xfs: di_flushiter considered harmful Dave Chinner
2013-07-22 11:07 ` Markus Trippelsdorf [this message]
2013-07-22 14:40   ` Mark Tinguely
2013-07-22 15:15     ` Markus Trippelsdorf
2013-07-22 16:37       ` Mark Tinguely
2013-07-22 19:48       ` Mark Tinguely
2013-07-23 10:42         ` [PATCH v2] " Markus Trippelsdorf
2013-07-23 15:07           ` Ben Myers
2013-07-23 15:56             ` Markus Trippelsdorf
2013-07-22 22:56   ` [PATCH] " Dave Chinner
2013-07-23  1:28     ` Markus Trippelsdorf
2013-07-23  4:49       ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2013-07-24  5:47 Dave Chinner
2013-07-24 17:16 ` Ben Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130722110732.GA365@x4 \
    --to=markus@trippelsdorf.de \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.