From: Richard Weinberger <richard@nod.at> To: "Rafał Miłecki" <zajec5@gmail.com> Cc: Artem Bityutskiy <dedekind1@gmail.com>, Amir Goldstein <amir73il@gmail.com>, Adrian Hunter <adrian.hunter@intel.com>, linux-unionfs@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>, linux-mtd@lists.infradead.org, Russell Senior <russell@personaltelco.net>, linux-fsdevel@vger.kernel.org, OpenWrt Development List <openwrt-devel@lists.openwrt.org> Subject: Re: Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up") Date: Sat, 27 Oct 2018 21:33:56 +0200 [thread overview] Message-ID: <6556017.quyC1DpDMg@blindfold> (raw) In-Reply-To: <CACna6rzvzc-_X3VDeA-nwtTW7KHaQGtbvzjVNoOFEQuHKi3PJg@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1088 bytes --] Rafał, Am Montag, 22. Oktober 2018, 17:34:44 CEST schrieb Rafał Miłecki: > Then I took a close look at ovl_copy_up_locked() and it seems above > info isn't accurate. It seems to me that setxattr() happens between > fsync and link. I modified my C app to follow that order (open, write, > fsync, setxattr, link) and I can reproduce the problem now! > > Steps to reproduce the problem: > 1) compile tmptest.c > 2) tmptest /overlay/upper/foo.txt user.bar baz > 3) wait 5 seconds (so ubifs writes to flash) > 4) power cut > 5) boot again and check content of /overlay/upper/foo.txt > 6) in my case content appears to be 00 00 00 00 Just returned from Edinburgh and had a chance to look at the problem. The problem is not that no write-back happens, in fact it happens just fine. But we have a problem upon journal replay if an unlinked file (O_TMPFILE) gets relinked in combination with xattrs. Can you please give the attached patch a try? It is not perfect but if I understand the problem correctly it should fix the issues you're facing. Thanks, //richard [-- Attachment #2: replay_tmpfile_fix.diff --] [-- Type: text/x-patch, Size: 1263 bytes --] diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c index 4844538eb926..82b1244e4138 100644 --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -209,6 +209,19 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) return ubifs_tnc_remove_range(c, &min_key, &max_key); } +static bool inode_comes_back(struct ubifs_info *c, struct replay_entry *rino) +{ + struct replay_entry *r; + + list_for_each_entry(r, &c->replay_list, list) { + if (keys_cmp(c, &rino->key, &r->key) == 0 && + r->deletion == 0) + return true; + } + + return false; +} + /** * apply_replay_entry - apply a replay entry to the TNC. * @c: UBIFS file-system description object @@ -218,7 +231,7 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) */ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { - int err; + int err = 0; dbg_mntk(&r->key, "LEB %d:%d len %d deletion %d sqnum %llu key ", r->lnum, r->offs, r->len, r->deletion, r->sqnum); @@ -236,6 +249,9 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { ino_t inum = key_inum(c, &r->key); + if (inode_comes_back(c, r)) + break; + err = ubifs_tnc_remove_ino(c, inum); break; } [-- Attachment #3: Type: text/plain, Size: 144 bytes --] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at> To: "Rafał Miłecki" <zajec5@gmail.com> Cc: Amir Goldstein <amir73il@gmail.com>, Miklos Szeredi <miklos@szeredi.hu>, linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Artem Bityutskiy <dedekind1@gmail.com>, Adrian Hunter <adrian.hunter@intel.com>, linux-mtd@lists.infradead.org, Russell Senior <russell@personaltelco.net>, OpenWrt Development List <openwrt-devel@lists.openwrt.org> Subject: Re: Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up") Date: Sat, 27 Oct 2018 21:33:56 +0200 [thread overview] Message-ID: <6556017.quyC1DpDMg@blindfold> (raw) In-Reply-To: <CACna6rzvzc-_X3VDeA-nwtTW7KHaQGtbvzjVNoOFEQuHKi3PJg@mail.gmail.com> [-- Attachment #1: Type: text/plain, Size: 1088 bytes --] Rafał, Am Montag, 22. Oktober 2018, 17:34:44 CEST schrieb Rafał Miłecki: > Then I took a close look at ovl_copy_up_locked() and it seems above > info isn't accurate. It seems to me that setxattr() happens between > fsync and link. I modified my C app to follow that order (open, write, > fsync, setxattr, link) and I can reproduce the problem now! > > Steps to reproduce the problem: > 1) compile tmptest.c > 2) tmptest /overlay/upper/foo.txt user.bar baz > 3) wait 5 seconds (so ubifs writes to flash) > 4) power cut > 5) boot again and check content of /overlay/upper/foo.txt > 6) in my case content appears to be 00 00 00 00 Just returned from Edinburgh and had a chance to look at the problem. The problem is not that no write-back happens, in fact it happens just fine. But we have a problem upon journal replay if an unlinked file (O_TMPFILE) gets relinked in combination with xattrs. Can you please give the attached patch a try? It is not perfect but if I understand the problem correctly it should fix the issues you're facing. Thanks, //richard [-- Attachment #2: replay_tmpfile_fix.diff --] [-- Type: text/x-patch, Size: 1263 bytes --] diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c index 4844538eb926..82b1244e4138 100644 --- a/fs/ubifs/replay.c +++ b/fs/ubifs/replay.c @@ -209,6 +209,19 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) return ubifs_tnc_remove_range(c, &min_key, &max_key); } +static bool inode_comes_back(struct ubifs_info *c, struct replay_entry *rino) +{ + struct replay_entry *r; + + list_for_each_entry(r, &c->replay_list, list) { + if (keys_cmp(c, &rino->key, &r->key) == 0 && + r->deletion == 0) + return true; + } + + return false; +} + /** * apply_replay_entry - apply a replay entry to the TNC. * @c: UBIFS file-system description object @@ -218,7 +231,7 @@ static int trun_remove_range(struct ubifs_info *c, struct replay_entry *r) */ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { - int err; + int err = 0; dbg_mntk(&r->key, "LEB %d:%d len %d deletion %d sqnum %llu key ", r->lnum, r->offs, r->len, r->deletion, r->sqnum); @@ -236,6 +249,9 @@ static int apply_replay_entry(struct ubifs_info *c, struct replay_entry *r) { ino_t inum = key_inum(c, &r->key); + if (inode_comes_back(c, r)) + break; + err = ubifs_tnc_remove_ino(c, inum); break; }
next prev parent reply other threads:[~2018-10-27 19:33 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-19 12:31 Regression in handling power cuts since 3a1e819b4e80 ("ovl: store file handle of lower inode on copy up") Rafał Miłecki 2018-10-19 12:31 ` Rafał Miłecki 2018-10-19 14:45 ` Richard Weinberger 2018-10-19 14:45 ` Richard Weinberger 2018-10-19 14:59 ` Richard Weinberger 2018-10-19 14:59 ` Richard Weinberger 2018-10-19 15:07 ` Amir Goldstein 2018-10-19 15:07 ` Amir Goldstein 2018-10-19 21:28 ` Rafał Miłecki 2018-10-19 21:28 ` Rafał Miłecki 2018-10-20 6:58 ` Richard Weinberger 2018-10-22 7:01 ` Rafał Miłecki 2018-10-22 7:01 ` Rafał Miłecki 2018-10-20 6:58 ` Richard Weinberger 2018-10-19 16:18 ` Rafał Miłecki 2018-10-19 16:18 ` Rafał Miłecki 2018-10-19 17:18 ` Richard Weinberger 2018-10-19 17:18 ` Richard Weinberger 2018-10-19 21:29 ` Rafał Miłecki 2018-10-19 21:29 ` Rafał Miłecki 2018-10-19 14:56 ` Amir Goldstein 2018-10-19 14:56 ` Amir Goldstein 2018-10-22 7:14 ` Rafał Miłecki 2018-10-22 7:14 ` Rafał Miłecki 2018-10-22 8:26 ` Richard Weinberger 2018-10-22 8:26 ` Richard Weinberger 2018-10-22 8:26 ` Richard Weinberger 2018-10-22 8:57 ` Amir Goldstein 2018-10-22 8:57 ` Amir Goldstein 2018-10-22 15:34 ` Rafał Miłecki 2018-10-22 15:34 ` Rafał Miłecki 2018-10-22 17:00 ` Amir Goldstein 2018-10-22 17:00 ` Amir Goldstein 2018-10-27 19:33 ` Richard Weinberger [this message] 2018-10-27 19:33 ` Richard Weinberger 2018-10-28 7:09 ` Russell Senior 2018-10-22 21:23 ` Rafał Miłecki 2018-10-22 21:23 ` Rafał Miłecki 2018-10-22 21:27 ` Rafał Miłecki 2018-10-22 21:27 ` Rafał Miłecki
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=6556017.quyC1DpDMg@blindfold \ --to=richard@nod.at \ --cc=adrian.hunter@intel.com \ --cc=amir73il@gmail.com \ --cc=dedekind1@gmail.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-unionfs@vger.kernel.org \ --cc=miklos@szeredi.hu \ --cc=openwrt-devel@lists.openwrt.org \ --cc=russell@personaltelco.net \ --cc=zajec5@gmail.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: linkBe 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.