[LSF/MM TOPIC] do we really need PG_error at all?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Proposing this as a LSF/MM TOPIC, but it may turn out to be me just not
understanding the semantics here.

As I was looking into -ENOSPC handling in cephfs, I noticed that
PG_error is only ever tested in one place [1] __filemap_fdatawait_range,
which does this:

	if (TestClearPageError(page))
		ret = -EIO;

This error code will override any AS_* error that was set in the
mapping. Which makes me wonder...why don't we just set this error in the
mapping and not bother with a per-page flag? Could we potentially free
up a page flag by eliminating this?

The main argument I could see for keeping it is that removing it might
subtly change the behavior of sync_file_range if you have tasks syncing
different ranges in a file concurrently. I'm not sure if that would
break any guarantees though.

Even if we do need it, I think we might need some cleanup here anyway. A
lot of readpage operations end up setting that flag when they hit an
error. Isn't it wrong to return an error on fsync, just because we had a
read error somewhere in the file in a range that was never dirtied?

--
[1]: there is another place in f2fs, but it's more or less equivalent to
the call site in __filemap_fdatawait_range.

-- 
Jeff Layton <jlayton@xxxxxxxxxx>



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux