linux-kernel - PROBLEM: [2.6.22.1] Copying to full NFS dir

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 01 Aug 2007 17:00:21 +0200
From:	Raphael Manfredi <Raphael_Manfredi@...ox.com>
To:	linux-kernel@...r.kernel.org
Subject: PROBLEM: [2.6.22.1] Copying to full NFS dir

I've stumbled into a problem running 2.6.22.1 on both my NFS client and
my NFS server.  I've just upgraded from 2.4.31, so I have no idea whether
this is a new problem or if it is known in the 2.6.x series.

Here's a high-level description of the context:

* The NFS server has a directory which is full.
* That directory is mounted on the NFS client.
* The NFS client tries to "mv local-file /nfs/remote-dir/"
* local-file is big (typically 700 MiB).

What happens is:

* The "mv" takes a long long time and eventually fails, of course.
* The load on the NFS server (initially at 0) increases to about 8.
* Any access to the NFS-mounted dir from the client whilst "mv" is in
  progress stalls (e.g. ls -l /nfs/remote-dir).

I've tried to write my own "mv" in C to see which syscalls were involved.
What happens is:

* All the write() succeed with no error.
* The final close() returns -1 with either EINTR or ENOSPC.

I could not determine what makes close return EINTR or ENOSPC.

Problem is, under 2.4.31, the write() was immediately failing when writing
to a full NFS partition.

This looks like an important bug, but I don't know if it is in the NFS-client
or NFS-server side.  I'm tempted to say NFS-server, but that's more a hunch.

Raphael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/