From: "Stephen M. Kenton" <skenton@ou.edu>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: new special filesystem for consideration in 2.6/2.7
Date: Sun, 07 Mar 2004 18:07:13 -0600 [thread overview]
Message-ID: <404BB931.1D3C83E8@ou.edu> (raw)
>> If the recent news about giga-bit mram being a real possibility in
>> the not too far future pans out, this may be get more important.
>This is a reality in embedded devices. Go read the message again...
Umm, yes and no. I did not mean to dis this proposal because I think it
is worthwhile. Rather, I was thinking about the problems with really
large amounts of data. I don't really think that a few Kilo or Mega
bytes of data needs the same sort of infrastructure that will be
required
for Tera or Peta bytes. As an extreme example the few bytes of nv ram
in the
cmos clock chips in the original PC/AT did not require much support
while
the multiple terabytes of data in my raid farm at work would be very
vulnerable under this proposal since a rogue process could cause lots of
damage in very sort order as would losing a memory bank to hardware
failure.
In the last discussion I saw on the topic on lkml, there was discussion
about
whether to even preserve the volume/directory/file abstraction at all
for
memory mapped data spaces. That discussion was quite speculative given
the lack of affordable *really large* nvram type storage to compete with
100+ gigabyte disks and even larger raids. That situation may be
changing.
Hence, this may become more important.
smk
next reply other threads:[~2004-03-08 5:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-08 0:07 Stephen M. Kenton [this message]
2004-03-08 18:37 ` new special filesystem for consideration in 2.6/2.7 Steve Longerbeam
-- strict thread matches above, loose matches on Subject: below --
2004-03-05 18:53 Steve Kenton
2004-03-07 3:07 ` Mike Fedyk
2004-03-03 18:57 Steve Longerbeam
2004-03-05 18:09 ` Steve Longerbeam
2004-03-05 18:42 ` Dave Jones
2004-03-05 18:59 ` Steve Longerbeam
2004-03-07 3:06 ` Mike Fedyk
2004-03-18 19:28 ` Tim Bird
2004-03-05 22:09 ` Pavel Machek
2004-03-08 17:57 ` Steve Longerbeam
2004-03-08 22:35 ` Pavel Machek
2004-03-07 9:49 ` Christoph Hellwig
2004-03-07 10:10 ` Willy Tarreau
2004-03-08 18:42 ` Steve Longerbeam
2004-03-11 12:34 ` Adrian Bunk
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=404BB931.1D3C83E8@ou.edu \
--to=skenton@ou.edu \
--cc=linux-kernel@vger.kernel.org \
/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