From: Spelic <spelic@shiftmail.org>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, linux-lvm@redhat.com
Subject: [linux-lvm] Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
Date: Thu, 02 Dec 2010 14:55:05 +0100 [thread overview]
Message-ID: <4CF7A539.1050206@shiftmail.org> (raw)
Hello all
I noticed what seem to be 4 bugs.
(kernel v2.6.37-rc4 but probably also before)
First two are one in mkfs.xfs and one in device mapper (lvm mailing list
I suppose, otherwise pls forward it):
Steps to reproduce:
Boot with a large ramdisk, like ramdisk_size=2097152
(actually I had 14GB ramdisk when I tried this but I don't think it will
make a difference)
Now partition it with a 1GB partition:
fdisk /dev/ram0
n
p
1
1
+1G
w
(only one 1GB physical partition)
Make a devmapper mapping for the partition
kpartx -av /dev/ram0
mkfs.xfs -f /dev/mapper/ram0p1
meta-data=/dev/mapper/ram0p1 isize=256 agcount=4,
agsize=66266 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=265064, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Now, lo and behold, partition is gone!
fdisk /dev/ram0
p
will show no partitions!
you can also check with
dd if=/dev/ram bs=1M count=1 | hexdump -C
All first MB of /dev/ram is zeroed!!
also
mount /dev/ram0p1 /mnt
will fail. Unknown filesystem
I think this shows 2 bugs: firstly mkfs.xfs dares to do stuff before the
beginning of the device on which it should work.
Secondly, device mapper does not constrain access within the boundaries
of the device, which I think it should do.
Then I have 2 more bugs for you. Please see my thread in linux-rdma called:
"NFS-RDMA hangs: connection closed (-103)"
in particular this post
http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg06632.html
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 the size of the
device (1.5GB): one bug I think is for XFS people (because I think XFS
should check if the space on the filesystem is finished), and another
one I think is for /dev/ram people (what mailing list? I am adding
lkml), because I think the device should check if someone is writing
beyond the end of it.
Thank you
PS: I am not subscribed to lkml so please do not reply ONLY to lkml.
next reply other threads:[~2010-12-02 13:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-02 13:55 Spelic [this message]
2010-12-02 14:11 ` [linux-lvm] Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram 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
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=4CF7A539.1050206@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).