From: Spelic <spelic@shiftmail.org>
To: Spelic <spelic@shiftmail.org>
Cc: linux-lvm@redhat.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com
Subject: Re: [linux-lvm] Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
Date: Thu, 02 Dec 2010 15:14:39 +0100 [thread overview]
Message-ID: <4CF7A9CF.2020904@shiftmail.org> (raw)
In-Reply-To: <4CF7A539.1050206@shiftmail.org>
Sorry for replying to my own email already
one more thing on the 3rd bug:
On 12/02/2010 02:55 PM, Spelic wrote:
> Hello all
> [CUT]
> .......
> with NFS over <RDMA or IPoIB> over Infiniband over XFS over ramdisk it
> is possible to write a file (2.3GB) which is larger than
This is also reproducible with:
NFS over TCP over Ethernet over XFS over ramdisk.
You don't need infiniband for this.
With ethernet it doesn't hang (that's another bug, for RDMA people, in
the othter thread) but the file is still 1.9GB, i.e. larger than the device.
Look, after running the test over ethernet,
at server side:
# ll -h /mnt/ram
total 1.5G
drwxr-xr-x 2 root root 21 2010-12-02 12:54 ./
drwxr-xr-x 3 root root 4.0K 2010-11-29 23:51 ../
-rw-r--r-- 1 root root 1.9G 2010-12-02 15:04 zerofile
# mount
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
devtmpfs on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
nfsd on /proc/fs/nfsd type nfsd (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)
/dev/ram0 on /mnt/ram type xfs (rw)
# blockdev --getsize64 /dev/ram0
1610612736
# dd if=/mnt/ram/zerofile | wc -c
1985937408
3878784+0 records in
3878784+0 records out
1985937408 bytes (2.0 GB) copied, 6.57081 s, 302 MB/s
Feel free to forward to NFS mailing list also if you think it's appropriate.
Thank you
next prev parent reply other threads:[~2010-12-02 14:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 13:55 [linux-lvm] Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Spelic
2010-12-02 14:11 ` Christoph Hellwig
2010-12-02 14:14 ` Spelic
2010-12-02 14:17 ` Christoph Hellwig
2010-12-02 21:22 ` Mike Snitzer
2010-12-02 22:08 ` Mike Snitzer
2010-12-03 17:11 ` Nick Piggin
2010-12-03 18:15 ` Ted Ts'o
2010-12-02 14:14 ` Spelic [this message]
2010-12-02 23:07 ` Dave Chinner
2010-12-03 14:07 ` Spelic
2010-12-06 4:09 ` Dave Chinner
2010-12-06 12:20 ` [linux-lvm] NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram) Spelic
2010-12-06 13:33 ` Trond Myklebust
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=4CF7A9CF.2020904@shiftmail.org \
--to=spelic@shiftmail.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
--cc=xfs@oss.sgi.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).