From: Ted Ts'o <tytso@mit.edu>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Mike Snitzer <snitzer@redhat.com>,
LVM general discussion and development <linux-lvm@redhat.com>,
Spelic <spelic@shiftmail.org>,
Christoph Hellwig <hch@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, dm-devel@redhat.com
Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
Date: Fri, 3 Dec 2010 13:15:20 -0500 [thread overview]
Message-ID: <20101203181520.GA26906@thunk.org> (raw)
In-Reply-To: <20101203171140.GA11889@amd>
On Sat, Dec 04, 2010 at 04:11:40AM +1100, Nick Piggin wrote:
> > Alternatively, what about switching brd away from overloading BLKFLSBUF
> > to a real implementation of (overloaded) BLKDISCARD support in brd.c?
> > One that doesn't blindly nuke the entire device but that properly
> > processes the discard request.
>
> Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk
> for the same reason).
>
> I want to unfortunately keep ioctl for compatibility, but adding new
> saner ones would be welcome. Also, having a non-default config or
> load time parameter for brd, to skip the special case, if that would
> help testing on older userspace.
How many programs actually depend on BLKFLSBUF dropping the pages used
in /dev/ram? The fact that it did this at all was a historical
accident of how the original /dev/ram was implemented (in the buffer
cache directly), and not anything that was intended. I think that's
something that we should be able to fix, since the number of programs
that knowly operate on the ramdisk is quite small. Just a few system
programs used by distributions in their early boot scripts....
So I would argue for dropping the "special" behavior of BLKFLSBUF for
/dev/ram.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Ted Ts'o" <tytso@mit.edu>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Mike Snitzer <snitzer@redhat.com>,
LVM general discussion and development <linux-lvm@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
dm-devel@redhat.com, Spelic <spelic@shiftmail.org>
Subject: Re: [linux-lvm] Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
Date: Fri, 3 Dec 2010 13:15:20 -0500 [thread overview]
Message-ID: <20101203181520.GA26906@thunk.org> (raw)
In-Reply-To: <20101203171140.GA11889@amd>
On Sat, Dec 04, 2010 at 04:11:40AM +1100, Nick Piggin wrote:
> > Alternatively, what about switching brd away from overloading BLKFLSBUF
> > to a real implementation of (overloaded) BLKDISCARD support in brd.c?
> > One that doesn't blindly nuke the entire device but that properly
> > processes the discard request.
>
> Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk
> for the same reason).
>
> I want to unfortunately keep ioctl for compatibility, but adding new
> saner ones would be welcome. Also, having a non-default config or
> load time parameter for brd, to skip the special case, if that would
> help testing on older userspace.
How many programs actually depend on BLKFLSBUF dropping the pages used
in /dev/ram? The fact that it did this at all was a historical
accident of how the original /dev/ram was implemented (in the buffer
cache directly), and not anything that was intended. I think that's
something that we should be able to fix, since the number of programs
that knowly operate on the ramdisk is quite small. Just a few system
programs used by distributions in their early boot scripts....
So I would argue for dropping the "special" behavior of BLKFLSBUF for
/dev/ram.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Ted Ts'o" <tytso@mit.edu>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Mike Snitzer <snitzer@redhat.com>,
LVM general discussion and development <linux-lvm@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xfs@oss.sgi.com, Christoph Hellwig <hch@infradead.org>,
dm-devel@redhat.com, Spelic <spelic@shiftmail.org>
Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
Date: Fri, 3 Dec 2010 13:15:20 -0500 [thread overview]
Message-ID: <20101203181520.GA26906@thunk.org> (raw)
In-Reply-To: <20101203171140.GA11889@amd>
On Sat, Dec 04, 2010 at 04:11:40AM +1100, Nick Piggin wrote:
> > Alternatively, what about switching brd away from overloading BLKFLSBUF
> > to a real implementation of (overloaded) BLKDISCARD support in brd.c?
> > One that doesn't blindly nuke the entire device but that properly
> > processes the discard request.
>
> Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk
> for the same reason).
>
> I want to unfortunately keep ioctl for compatibility, but adding new
> saner ones would be welcome. Also, having a non-default config or
> load time parameter for brd, to skip the special case, if that would
> help testing on older userspace.
How many programs actually depend on BLKFLSBUF dropping the pages used
in /dev/ram? The fact that it did this at all was a historical
accident of how the original /dev/ram was implemented (in the buffer
cache directly), and not anything that was intended. I think that's
something that we should be able to fix, since the number of programs
that knowly operate on the ramdisk is quite small. Just a few system
programs used by distributions in their early boot scripts....
So I would argue for dropping the "special" behavior of BLKFLSBUF for
/dev/ram.
- Ted
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-12-03 18:15 UTC|newest]
Thread overview: 42+ 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 13:55 ` Spelic
2010-12-02 13:55 ` Spelic
2010-12-02 14:11 ` [linux-lvm] " Christoph Hellwig
2010-12-02 14:11 ` Christoph Hellwig
2010-12-02 14:11 ` Christoph Hellwig
2010-12-02 14:14 ` [linux-lvm] " Spelic
2010-12-02 14:14 ` Spelic
2010-12-02 14:14 ` Spelic
2010-12-02 14:17 ` [linux-lvm] " Christoph Hellwig
2010-12-02 14:17 ` Christoph Hellwig
2010-12-02 14:17 ` Christoph Hellwig
2010-12-02 21:22 ` Mike Snitzer
2010-12-02 21:22 ` Mike Snitzer
2010-12-02 21:22 ` [linux-lvm] " Mike Snitzer
2010-12-02 22:08 ` Mike Snitzer
2010-12-02 22:08 ` Mike Snitzer
2010-12-02 22:08 ` [linux-lvm] " Mike Snitzer
2010-12-03 17:11 ` Nick Piggin
2010-12-03 17:11 ` Nick Piggin
2010-12-03 17:11 ` [linux-lvm] " Nick Piggin
2010-12-03 18:15 ` Ted Ts'o [this message]
2010-12-03 18:15 ` Ted Ts'o
2010-12-03 18:15 ` [linux-lvm] " Ted Ts'o
2010-12-02 14:14 ` Spelic
2010-12-02 14:14 ` Spelic
2010-12-02 14:14 ` Spelic
2010-12-02 23:07 ` [linux-lvm] " Dave Chinner
2010-12-02 23:07 ` Dave Chinner
2010-12-02 23:07 ` Dave Chinner
2010-12-03 14:07 ` [linux-lvm] " Spelic
2010-12-03 14:07 ` Spelic
2010-12-03 14:07 ` Spelic
2010-12-06 4:09 ` [linux-lvm] " Dave Chinner
2010-12-06 4:09 ` Dave Chinner
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 12:20 ` Spelic
2010-12-06 12:20 ` Spelic
2010-12-06 13:33 ` [linux-lvm] " Trond Myklebust
2010-12-06 13:33 ` Trond Myklebust
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=20101203181520.GA26906@thunk.org \
--to=tytso@mit.edu \
--cc=dm-devel@redhat.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
--cc=npiggin@kernel.dk \
--cc=snitzer@redhat.com \
--cc=spelic@shiftmail.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.