From: Gao Xiang <gaoxiang25@huawei.com>
To: Pavel Machek <pavel@denx.de>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Theodore Ts'o <tytso@mit.edu>, David Sterba <dsterba@suse.cz>,
Amir Goldstein <amir73il@gmail.com>,
Christoph Hellwig <hch@infradead.org>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
"Jaegeuk Kim" <jaegeuk@kernel.org>, Jan Kara <jack@suse.cz>,
Richard Weinberger <richard@nod.at>,
Linus Torvalds <torvalds@linux-foundation.org>,
<devel@driverdev.osuosl.org>, <linux-erofs@lists.ozlabs.org>,
Chao Yu <yuchao0@huawei.com>, Miao Xie <miaoxie@huawei.com>,
Li Guifu <bluce.liguifu@huawei.com>,
Fang Wei <fangwei1@huawei.com>
Subject: Re: [PATCH v7 08/24] erofs: add namei functions
Date: Tue, 13 Aug 2019 20:23:32 +0800 [thread overview]
Message-ID: <20190813122332.GA17429@138> (raw)
In-Reply-To: <20190813114821.GB11559@amd>
Hi Pavel,
On Tue, Aug 13, 2019 at 01:48:21PM +0200, Pavel Machek wrote:
> Hi!
>
> > + /*
> > + * on-disk error, let's only BUG_ON in the debugging mode.
> > + * otherwise, it will return 1 to just skip the invalid name
> > + * and go on (in consideration of the lookup performance).
> > + */
> > + DBG_BUGON(qd->name > qd->end);
>
> I believe you should check for errors in non-debug mode, too.
Thanks for your kindly reply!
The following is just my personal thought... If I am wrong, please
kindly point out...
As you can see, this is a new prefixed string binary search algorithm
which can provide similar performance with hashed approach (but no
need to store hash value at all), so I really care about its lookup
performance.
There is something needing to be concerned, is, whether namei() should
report any potential on-disk issues or just return -ENOENT for these
corrupted dirs, I think I tend to use the latter one.
The reason (in my opinion) is if you consider another some another
complicated non-transverse ondisk implementation, it cannot transverse
all the entires so they could/couldn't report all potential issues
in namei() (For such corrupted dir, they can return -ENOENT due
to lack of information of course, just avoiding crashing the kernel
is OK).
Therefore, in my thought, such issue can be reported by fsck-like
tools such as erofs.fsck. And actually readdir() will also report
all issues as well, thus we can have performance gain on lookup.
>
>
> > + if (unlikely(!ndirents)) {
> > + DBG_BUGON(1);
> > + kunmap_atomic(de);
> > + put_page(page);
> > + page = ERR_PTR(-EIO);
> > + goto out;
> > + }
>
> -EUCLEAN is right error code for corrupted filesystem. (And you
> probably want to print something to the syslog, too).
Yes, you are right :) -EUCLEAN/EFSCORRUPTED is actually for such thing,
nowadays, EROFS treats all EFSCORRUPTED cases into EIO, and I will
update that in one patch... (Yes, it needs to print something of course :))
Thanks,
Gao Xiang
>
> Pavel
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
next prev parent reply other threads:[~2019-08-13 12:06 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 9:13 [PATCH v7 00/24] erofs: promote erofs from staging Gao Xiang
2019-08-13 9:13 ` [PATCH v7 01/24] erofs: add on-disk layout Gao Xiang
2019-08-13 9:13 ` [PATCH v7 02/24] erofs: add erofs in-memory stuffs Gao Xiang
2019-08-13 9:13 ` [PATCH v7 03/24] erofs: add super block operations Gao Xiang
2019-08-13 9:13 ` [PATCH v7 04/24] erofs: add raw address_space operations Gao Xiang
2019-08-13 9:13 ` [PATCH v7 05/24] erofs: add inode operations Gao Xiang
2019-08-13 9:13 ` [PATCH v7 06/24] erofs: support special inode Gao Xiang
2019-08-13 9:13 ` [PATCH v7 07/24] erofs: add directory operations Gao Xiang
2019-08-13 9:13 ` [PATCH v7 08/24] erofs: add namei functions Gao Xiang
2019-08-13 11:48 ` Pavel Machek
2019-08-13 12:23 ` Gao Xiang [this message]
2019-08-13 12:41 ` Gao Xiang
2019-08-15 7:01 ` Pavel Machek
2019-08-15 7:25 ` Gao Xiang
2019-08-13 9:13 ` [PATCH v7 09/24] erofs: support tracepoint Gao Xiang
2019-08-13 9:13 ` [PATCH v7 10/24] erofs: update Kconfig and Makefile Gao Xiang
2019-08-13 9:13 ` [PATCH v7 11/24] erofs: introduce xattr & posixacl support Gao Xiang
2019-08-13 9:13 ` [PATCH v7 12/24] erofs: introduce tagged pointer Gao Xiang
2019-08-13 9:13 ` [PATCH v7 13/24] erofs: add compression indexes support Gao Xiang
2019-08-13 9:13 ` [PATCH v7 14/24] erofs: introduce superblock registration Gao Xiang
2019-08-13 9:13 ` [PATCH v7 15/24] erofs: introduce erofs shrinker Gao Xiang
2019-08-13 9:13 ` [PATCH v7 16/24] erofs: introduce workstation for decompression Gao Xiang
2019-08-13 9:13 ` [PATCH v7 17/24] erofs: introduce per-CPU buffers implementation Gao Xiang
2019-08-13 9:13 ` [PATCH v7 18/24] erofs: introduce pagevec for decompression subsystem Gao Xiang
2019-08-13 9:13 ` [PATCH v7 19/24] erofs: add erofs_allocpage() Gao Xiang
2019-08-13 9:13 ` [PATCH v7 20/24] erofs: introduce generic decompression backend Gao Xiang
2019-08-13 9:13 ` [PATCH v7 21/24] erofs: introduce LZ4 decompression inplace Gao Xiang
2019-08-13 9:13 ` [PATCH v7 22/24] erofs: introduce the decompression frontend Gao Xiang
2019-08-13 9:13 ` [PATCH v7 23/24] erofs: introduce cached decompression Gao Xiang
2019-08-13 9:13 ` [PATCH v7 24/24] erofs: add document Gao Xiang
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=20190813122332.GA17429@138 \
--to=gaoxiang25@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=bluce.liguifu@huawei.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=devel@driverdev.osuosl.org \
--cc=dsterba@suse.cz \
--cc=fangwei1@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miaoxie@huawei.com \
--cc=pavel@denx.de \
--cc=richard@nod.at \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=yuchao0@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).