From: Richard Neill <rn214@hermes.cam.ac.uk>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] What is the minimal linux setup for running Qemu ?
Date: Thu, 23 Dec 2004 01:40:57 +0000 [thread overview]
Message-ID: <41CA2229.9060706@hermes.cam.ac.uk> (raw)
In-Reply-To: <001201c4e881$0e9a1260$964aa50c@computername>
jeebs wrote:
>> Metropipe's product is actually quite interesting, since they aim
>> to store all your files on their server, and the memory key
>> provides firefox,ssh etc and a virtual private network.
>
>
> There's nothing on the web site about that.
>
> Their VPM page talks about storing things 'in your pocket' etc., so
> it sounds like just a typical local virtual drive right on the memory
> device itself. That's what prompted to me make my comment in here.
>
> They do provide a demo of their tunneler, but I don't see anything
> about the product requiring its use etc. etc.
>
>
I downloaded their demo, but replaced their metropipe iso with the
"regular" Damn Small Linux iso. It does work well.
>>> Any virtual disk is going to do quite a few writes, and flash
>>> memory can only do so many before it starts to fail.
>>
>> I thought this number was > 100,000 - so it's still not really an
>> issue except for atime and swap.
>
>
> I really don't know what the cycle count is. Certainly on the higher
> quality flash chips, it's over a million bit write cycles. But with
> so many ultra cheap memory sticks with memory from no telling where,
> it's not something I'd want to depend on for more than a few tens of
> thousand writes per bit. And unless there is proof to the contrary
> about the OS and the apps, you kind of have to assume that anytime
> you actually run any programs, it's going to update a directory or a
> config file, or whatever.
>
Running the OS cannot do any writing, since the ISO expects to be a
CDROM, and is read-only. Furthermore, Knoppix normally expects /home
(and /tmp) to be a RAMdisk. This means that the apps won't save their
config files by default.
> Maybe I'm wrong, but at this point, I find it hard to believe that
> it's not going to be doing lots of writes to the virtual disk when
> you actually use stuff, like MetroPipe is trying to suggest. Simply
> booting it for a demonstration or the ocasional emergency, etc. is no
> problem. But MetroPipe is talking about actually using it for real,
> and I'm real hesitant about the life span of the flash area where the
> directories are at. Unless MetroPipe has taken explicit
> steps to reduce this and I don't know about it.
> There isn't enough information of the web site to say for sure how
> it's set up (I haven't tried it yet), but I'd guess it's nothing more
> than a typical virtual disk for storage of your stuff, and an ISO for
> the linux. Just a simple, no frills setup involving qemu, an empty
> virtual disk, and a standard DSL iso image. That's why I said it was
> interesting, but not inovative. (If I'm wrong, then great!)
>
>
Exactly. And as you say, the problem is that writing to files in a
virtual disk means that any slight corruption to the real physical file
may completely destroy the filesystem on the virtual disk. A crash of
the host would also be less damaging.
What *would* be cute would be to use the virtual vfat driver. Thus files
on the guest map to real files on the memory key. If you do this, the
number of writes will be exactly the same as if you used the memory key
for transport of files in the usual way.
My ideal set up would be the following:
USB-memory-key/
/qemu/mac <- mac binaries for qemu and bios
/qemu/linux <- linux binaries for qemu and bios
/qemu/win <- windows binaries for qemu and bios
/dsl/iso <- dsl iso itself
/dsl/extras <- extra apps for dsl if desired.
/myfiles <- an ordinary directory, not a disk image.
appearing to the guest as a drive using
virtual vfat
/putty <- ssh binaries for win,linux,mac
/vnc <- vnc viewer binaries for win,linux,mac
win-startup.bat <- start up scripts for qemu/dsl
mac-startup.sh
linux-startup.sh
The only problems that remain are:
- vfat doesn't support Linux file attributes.
(there is a solution, but I forget what).
- you need a script to manually save those files within /home
that you want to keep. Most can vanish with the ramdisk on
reboot, but things like ~/.ssh and ~/.mozilla are useful!
[DSL and Knoppix both solve this problem somehow ]
In addition, with the falling prices of memory keys, an entire knoppix
iso could be used, if desired. Furthermore, since we know exactly what
the emulated hardware will be, knoppix could be compiled with the
appropriate optimisations.
Regards
Richard
next prev parent reply other threads:[~2004-12-23 1:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-22 16:20 [Qemu-devel] What is the minimal linux setup for running Qemu ? Khan, Mohammad
2004-12-22 16:40 ` Richard Neill
2004-12-22 20:31 ` jeebs
2004-12-22 23:09 ` Richard Neill
2004-12-22 23:50 ` jeebs
2004-12-23 1:40 ` Richard Neill [this message]
2004-12-23 2:02 ` Jim C. Brown
2004-12-23 18:36 ` Andreas Bollhalder
2004-12-23 23:12 ` Jim C. Brown
2004-12-23 2:41 ` [Qemu-devel] " Ronald
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=41CA2229.9060706@hermes.cam.ac.uk \
--to=rn214@hermes.cam.ac.uk \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).