listreader@... said:
> The shadow feature means altered data are written to an altered file.
> It simplifies rollback in the event of corruption, and also allows
> different virtual machines to have a common filesystem (or even to
> mount from CD), just so long as there's a writable shadow.
Greg Lonnon has this in the works. Haven't thought about compression though.
Jeff

Thread view

stevegt@... said:
> Looks like a debian thing then. Is your debian filesystem potato and/
> or related to the root_fs_debian2.2_small you have posted on
> sourceforge?
I'm thinking that ping changed how it does timing, and the method that the
Debian ping uses is broken in UML.
> Okay -- let us know if you ever need any help with either politics or
> technology to make it happen;
OK, but it shouldn't be a problem. If it's at all sane, there's a real use
for it, and it doesn't affect anyone who doesn't use it, it's not hard to get
it in.
> this sounds like it would be a huge
> performance boost (Factor of 2? 3? Am I thinking right?).
Roughly, it depends on workload, obviously. This aspect of UML is essentially
the same as strace, so you can get an estimate by looking at strace overhead.
For the 'ls -Ral' workload, I get the following (after running it one to prime
the OS caches):
% time ls -Ral . > /dev/null
4.73user 16.77system 1:57.09elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (141major+1027minor)pagefaults 0swaps
% time strace -o /dev/null ls -Ral . > /dev/null
15.27user 24.33system 1:15.28elapsed 52%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (294major+1059minor)pagefaults 0swaps
So, in this case (which is IO and system call intensive), I would expect
something like a 2 times speedup for UML (and a much lighter load on the
system, apparently).
> The other major improvement would still be multithreading block device
> I/O, right?
I think so. It would certainly improve readaheads. I'm going to implement
that with aio when it appears in the mainline kernel. The other possibility
is with one IO thread per outstanding request, but that's too gross for me...
Jeff

listreader@... said:
> The shadow feature means altered data are written to an altered file.
> It simplifies rollback in the event of corruption, and also allows
> different virtual machines to have a common filesystem (or even to
> mount from CD), just so long as there's a writable shadow.
Greg Lonnon has this in the works. Haven't thought about compression though.
Jeff

Jeff Dike <jdike@...> writes:
> listreader@... said:
> > The shadow feature means altered data are written to an altered file.
> > It simplifies rollback in the event of corruption, and also allows
> > different virtual machines to have a common filesystem (or even to
> > mount from CD), just so long as there's a writable shadow.
>
> Greg Lonnon has this in the works. Haven't thought about compression though.
I have a complete MVS system in 76 Mbytes. You don't need much compression to make an enormous saving on unfilled disks.
There's a document at the Hercules website that describes how it works.
--
Cheers
JS

Jeff Dike wrote:
> I'm thinking that ping changed how it does timing, and the method that =
the
> Debian ping uses is broken in UML.
An strace of the broken ping should tell quite quickly.
As far as I know the syscall interface does not normally expose HZ in tim=
ing so I
am afraid it MAY be a case of some part of the UML kernel doing time conv=
ersion
to/from jiffies in a bad manner.
--
Henrik Nordstr=F6m
MARA Systems

Jeff Dike <jdike@...> writes:
.
>
> > The other major improvement would still be multithreading block device
> > I/O, right?
>
> I think so. It would certainly improve readaheads. I'm going to implement
> that with aio when it appears in the mainline kernel. The other possibility
> is with one IO thread per outstanding request, but that's too gross for me...
Hercules has one I/O thread and according to folk with more powerful computers than mine, it's fine.
An idea from Hercules that's worth pinching is disk compression and shadowing (two ideas)
It packs tracks of data and maintains an index to them Saves heaps of space and I've been running MVS quite happily on a Pentium 133.
The shadow feature means altered data are written to an altered file. It simplifies rollback in the event of corruption, and also allows different virtual machines to have a common filesystem (or even to mount from CD), just so long as there's a writable shadow.
.
--
Cheers
JS