Skip to content

K
Kernel

openeuler / Kernel
2 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 26 2月, 2022 1 次提交
  3. 10 1月, 2022 1 次提交
  5. 11 9月, 2021 1 次提交
    • J
      locks: remove LOCK_MAND flock lock support · 90f7d7a0
      由 Jeff Layton 提交于 
      As best I can tell, the logic for these has been broken for a long time
(at least before the move to git), such that they never conflict with
anything. Also, nothing checks for these flags and prevented opens or
read/write behavior on the files. They don't seem to do anything.

Given that, we can rip these symbols out of the kernel, and just make
flock(2) return 0 when LOCK_MAND is set in order to preserve existing
behavior.

Cc: Matthew Wilcox <willy@infradead.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJeff Layton <jlayton@kernel.org>
      90f7d7a0
  7. 27 8月, 2021 1 次提交
  9. 23 8月, 2021 1 次提交
    • J
      fs: remove mandatory file locking support · f7e33bdb
      由 Jeff Layton 提交于 
      We added CONFIG_MANDATORY_FILE_LOCKING in 2015, and soon after turned it
off in Fedora and RHEL8. Several other distros have followed suit.

I've heard of one problem in all that time: Someone migrated from an
older distro that supported "-o mand" to one that didn't, and the host
had a fstab entry with "mand" in it which broke on reboot. They didn't
actually _use_ mandatory locking so they just removed the mount option
and moved on.

This patch rips out mandatory locking support wholesale from the kernel,
along with the Kconfig option and the Documentation file. It also
changes the mount code to ignore the "mand" mount option instead of
erroring out, and to throw a big, ugly warning.
Signed-off-by: NJeff Layton <jlayton@kernel.org>
      f7e33bdb
  11. 13 4月, 2021 1 次提交
  13. 17 2月, 2021 1 次提交
  15. 09 2月, 2021 3 次提交
  17. 05 8月, 2020 1 次提交
  19. 02 8月, 2020 1 次提交
  21. 18 7月, 2020 1 次提交
  23. 26 6月, 2020 1 次提交
    • O
      NFSv4 fix CLOSE not waiting for direct IO compeletion · d03727b2
      由 Olga Kornievskaia 提交于 
      Figuring out the root case for the REMOVE/CLOSE race and
suggesting the solution was done by Neil Brown.

Currently what happens is that direct IO calls hold a reference
on the open context which is decremented as an asynchronous task
in the nfs_direct_complete(). Before reference is decremented,
control is returned to the application which is free to close the
file. When close is being processed, it decrements its reference
on the open_context but since directIO still holds one, it doesn't
sent a close on the wire. It returns control to the application
which is free to do other operations. For instance, it can delete a
file. Direct IO is finally releasing its reference and triggering
an asynchronous close. Which races with the REMOVE. On the server,
REMOVE can be processed before the CLOSE, failing the REMOVE with
EACCES as the file is still opened.
Signed-off-by: NOlga Kornievskaia <kolga@netapp.com>
Suggested-by: NNeil Brown <neilb@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      d03727b2
  25. 15 1月, 2020 2 次提交
  27. 18 11月, 2019 1 次提交
  29. 21 5月, 2019 1 次提交
  31. 26 4月, 2019 2 次提交
  33. 21 2月, 2019 3 次提交
    • K
      pNFS: Avoid read/modify/write when it is not necessary · 2cde04e9
      由 Kazuo Ito 提交于 
      As the block and SCSI layouts can only read/write fixed-length
blocks, we must perform read-modify-write when data to be written is
not aligned to a block boundary or smaller than the block size.
(612aa983 pnfs: add flag to force read-modify-write in ->write_begin)

The current code tries to see if we have to do read-modify-write
on block-oriented pNFS layouts by just checking !PageUptodate(page),
but the same condition also applies for overwriting of any uncached
potions of existing files, making such operations excessively slow
even it is block-aligned.

The change does not affect the optimization for modify-write-read
cases (38c73044 NFS: read-modify-write page updating),
because partial update of !PageUptodate() pages can only happen
in layouts that can do arbitrary length read/write and never
in block-based ones.

Testing results:

We ran fio on one of the pNFS clients running 4.20 kernel
(vanilla and patched) in this configuration to read/write/overwrite
files on the storage array, exported as pnfs share by the server.

 pNFS clients ---1G Ethernet--- pNFS server
 (HP DL360 G8)                  (HP DL360 G8)
       |                              |
       |                              |
       +------8G Fiber Channel--------+
                     |
               Storage Array
                 (HP P6350)

Throughput of overwrite (both buffered and O_SYNC) is noticeably
improved.

Ops.     |block size|   Throughput   |
         |  (KiB)   |    (MiB/s)     |
         |          |  4.20 | patched|
---------+----------+----------------+
buffered |         4|  21.3 |  232   |
overwrite|        32|  22.2 |  256   |
         |       512|  22.4 |  260   |
---------+----------+----------------+
O_SYNC   |         4|   3.84|    4.77|
overwrite|        32|  12.2 |   32.0 |
         |       512|  18.5 |  152   |
---------+----------+----------------+

Read and write (buffered and O_SYNC) by the same client remain unchanged
by the patch either negatively or positively, as they should do.

Ops.     |block size|   Throughput   |
         |  (KiB)   |    (MiB/s)     |
         |          |  4.20 | patched|
---------+----------+----------------+
read     |         4| 548   |  550   |
         |        32| 547   |  551   |
         |       512| 548   |  551   |
---------+----------+----------------+
buffered |         4| 237   |  244   |
write    |        32| 261   |  268   |
         |       512| 265   |  272   |
---------+----------+----------------+
O_SYNC   |         4|   0.46|    0.46|
write    |        32|   3.60|    3.57|
         |       512| 105   |  106   |
---------+----------+----------------+
Signed-off-by: NKazuo Ito <ito_kazuo_g3@lab.ntt.co.jp>
Tested-by: NHiroyuki Watanabe <watanabe.hiroyuki@lab.ntt.co.jp>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      2cde04e9
    • K
      pNFS: Fix potential corruption of page being written · 97ae91bb
      由 Kazuo Ito 提交于 
      nfs_want_read_modify_write() didn't check for !PagePrivate when pNFS
block or SCSI layout was in use, therefore we could lose data forever
if the page being written was filled by a read before completion.
Signed-off-by: NKazuo Ito <ito_kazuo_g3@lab.ntt.co.jp>
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      97ae91bb
    • T
      NFS: Fix up documentation warnings · 302fad7b
      由 Trond Myklebust 提交于 
      Fix up some compiler warnings about function parameters, etc not being
correctly described or formatted.
Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      302fad7b
  35. 31 7月, 2018 1 次提交
  37. 18 11月, 2017 1 次提交
  39. 12 9月, 2017 1 次提交
    • N
      NFS: various changes relating to reporting IO errors. · bf4b4905
      由 NeilBrown 提交于 
      1/ remove 'start' and 'end' args from nfs_file_fsync_commit().
   They aren't used.

2/ Make nfs_context_set_write_error() a "static inline" in internal.h
   so we can...

3/ Use nfs_context_set_write_error() instead of mapping_set_error()
   if nfs_pageio_add_request() fails before sending any request.
   NFS generally keeps errors in the open_context, not the mapping,
   so this is more consistent.

4/ If filemap_write_and_write_range() reports any error, still
   check ctx->error.  The value in ctx->error is likely to be
   more useful.  As part of this, NFS_CONTEXT_ERROR_WRITE is
   cleared slightly earlier, before nfs_file_fsync_commit() is called,
   rather than at the start of that function.
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      bf4b4905
  41. 07 9月, 2017 2 次提交
  43. 27 7月, 2017 2 次提交
    • N
      NFS: Optimize fallocate by refreshing mapping when needed. · 6ba80d43
      由 NeilBrown 提交于 
      posix_fallocate() will allocate space in an NFS file by considering
the last byte of every 4K block.  If it is before EOF, it will read
the byte and if it is zero, a zero is written out.  If it is after EOF,
the zero is unconditionally written.

For the blocks beyond EOF, if NFS believes its cache is valid, it will
expand these writes to write full pages, and then will merge the pages.
This results if (typically) 1MB writes.  If NFS believes its cache is
not valid (particularly if NFS_INO_INVALID_DATA or
NFS_INO_REVAL_PAGECACHE are set - see nfs_write_pageuptodate()), it will
send the individual 1-byte writes. This results in (typically) 256 times
as many RPC requests, and can be substantially slower.

Currently nfs_revalidate_mapping() is only used when reading a file or
mmapping a file, as these are times when the content needs to be
up-to-date.  Writes don't generally need the cache to be up-to-date, but
writes beyond EOF can benefit, particularly in the posix_fallocate()
case.

So this patch calls nfs_revalidate_mapping() when writing beyond EOF -
i.e. when there is a gap between the end of the file and the start of
the write.  If the cache is thought to be out of date (as happens after
taking a file lock), this will cause a GETATTR, and the two flags
mentioned above will be cleared.  With this, posix_fallocate() on a
newly locked file does not generate excessive tiny writes.
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      6ba80d43
    • N
      NFS: invalidate file size when taking a lock. · 442ce049
      由 NeilBrown 提交于 
      Prior to commit ca0daa27 ("NFS: Cache aggressively when file is open
for writing"), NFS would revalidate, or invalidate, the file size when
taking a lock.  Since that commit it only invalidates the file content.

If the file size is changed on the server while wait for the lock, the
client will have an incorrect understanding of the file size and could
corrupt data.  This particularly happens when writing beyond the
(supposed) end of file and can be easily be demonstrated with
posix_fallocate().

If an application opens an empty file, waits for a write lock, and then
calls posix_fallocate(), glibc will determine that the underlying
filesystem doesn't support fallocate (assuming version 4.1 or earlier)
and will write out a '0' byte at the end of each 4K page in the region
being fallocated that is after the end of the file.
NFS will (usually) detect that these writes are beyond EOF and will
expand them to cover the whole page, and then will merge the pages.
Consequently, NFS will write out large blocks of zeroes beyond where it
thought EOF was.  If EOF had moved, the pre-existing part of the file
will be over-written.  Locking should have protected against this,
but it doesn't.

This patch restores the use of nfs_zap_caches() which invalidated the
cached attributes.  When posix_fallocate() asks for the file size, the
request will go to the server and get a correct answer.

cc: stable@vger.kernel.org (v4.8+)
Fixes: ca0daa27 ("NFS: Cache aggressively when file is open for writing")
Signed-off-by: NNeilBrown <neilb@suse.com>
Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      442ce049
  45. 27 4月, 2017 1 次提交
  47. 21 4月, 2017 2 次提交
  49. 25 2月, 2017 1 次提交
  51. 25 12月, 2016 1 次提交
  53. 20 12月, 2016 1 次提交
  55. 10 12月, 2016 1 次提交
    • A
      nfs_write_end(): fix handling of short copies · c0cf3ef5
      由 Al Viro 提交于 
      What matters when deciding if we should make a page uptodate is
not how much we _wanted_ to copy, but how much we actually have
copied.  As it is, on architectures that do not zero tail on
short copy we can leave uninitialized data in page marked uptodate.

Cc: stable@vger.kernel.org
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c0cf3ef5
  57. 05 12月, 2016 1 次提交
  59. 06 10月, 2016 1 次提交
  61. 23 9月, 2016 1 次提交