[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OFD1325B2C.7A926EF9-ON882575D6.00567314-882575D6.00571BC3@us.ibm.com>
Date: Mon, 15 Jun 2009 08:51:28 -0700
From: Bryan Henderson <hbryan@...ibm.com>
To: Artem Bityutskiy <dedekind1@...il.com>
Cc: Daniel Walker <dwalker@....ucsc.edu>,
Jamie Lokier <jamie@...reable.org>,
Linux Embedded <linux-embedded@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Marco <marco.stornelli@...il.com>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> Marco wrote:
> > To enable direct
> > I/O at all times for all regular files requires either that
> > applications be modified to include the O_DIRECT flag on all file
> > opens, or that a new filesystem be used that always performs direct
> > I/O by default."
>
> This could be done as well by just introducing a "direct_io_only"
> mount option to a file-system which would need this feature.
A mount option would not be the right way. Mount options are for things
that are characteristic of the way you're going to access the files.
_This_ is a characteristic of the block device. So if one were to make
this memory accessible with a block device, it would make more sense to
have a block device ioctl. And it wouldn't ask the question, "should I
use direct I/O only," but "does this device have the performance
characteristics of a classic disk drive?"
But it's possible that there's just no advantage to having a block device
in the stack here. When unix block devices were invented, their main
purpose was that they could reorder reads and writes and do buffering and
caching -- all things essential for disk drives. We don't want to stretch
the concept too far.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Storage Systems
--
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/
Powered by blists - more mailing lists