[9fans] running plan9 : an ideal setup?

[9fans] running plan9 : an ideal setup?

[Mayuresh Kathe]

i have been trying to get plan9 running on my latest and greatest hp-aio.
failed, even while trying out 9front.
would there be some way to determine an ideal configuration for a machine
to used solely for plan9 experimentation?
also, based on what ever i have read, plan9 seems most at home with a set
of machines in some kind of client-server mode. if this is true, may i
know an ideal setup?
thanks.

Re: [9fans] running plan9 : an ideal setup?

[dante]

Raspberry Pi with an Ethernet cable (unfortunately there's no wireless
yet AFAIK).
Both the Plan9 and the 9Front file systems have their issues, though, so
back up periodically:

- Plan9: don't enable periodic snapshots in Fossil to avoid it getting
corrupt
- 9Front: comes with the experimental hjfs by default, which got corrupt
sooner or later on my setup

Both distributions come as a small (2GB) runnable image.
There is no installer yet, so it is hard to change the file system.

What I did:

Boot Richard Miller's Plan9 SD card (2GB image) on a Raspberry Pi.
Used an USB-to-SD adapter and the clone script from an earlier post of
mine to install the system on a *larger* SD card.
Boot the large SD card, happy.

The said images are terminal servers.
If you manage to convert the terminal server into a CPU server (easy,
see Wiki), you'll be able to connect from Unix using drawterm.

Cheers,
Dante

On 18.11.2014 14:29, mayuresh@devio.us wrote:
> i have been trying to get plan9 running on my latest and greatest
> hp-aio.
> failed, even while trying out 9front.
> would there be some way to determine an ideal configuration for a
> machine
> to used solely for plan9 experimentation?
> also, based on what ever i have read, plan9 seems most at home with a
> set
> of machines in some kind of client-server mode. if this is true, may i
> know an ideal setup?
> thanks.

Re: [9fans] running plan9 : an ideal setup?

[Richard Miller]

> - Plan9: don't enable periodic snapshots in Fossil to avoid it getting
> corrupt

I think that advice refers to a bug which was fixed in March 2012.

Re: [9fans] running plan9 : an ideal setup?

[dante]

I'll test again and report if the issue is still there.

On 18.11.2014 15:11, Richard Miller wrote:
>> - Plan9: don't enable periodic snapshots in Fossil to avoid it getting
>> corrupt
>
> I think that advice refers to a bug which was fixed in March 2012.

Re: [9fans] running plan9 : an ideal setup?

[Dante]

So, I didn't get too far with my tests, except for what apparently is a
dead SD card, after about 3 Months uptime doing nothing.
This is not stellar compared with more than on year uptime with no
problems for a Linux running on the same Raspberry Pi (other SD card).

Does Plan9 record the access times of files?
Could this be a reason for the dead SD cards?
Is there any way to disable recording atimes?

Please note that the Linux "experiment" ran with atime disabled.
If this is the problem, I could install Plan9 onto a magnetic USB disk
and only boot from the SD.

What do you folks think?

Kind Regards,
Dante

On 18.11.2014 15:11, Richard Miller wrote:
>> - Plan9: don't enable periodic snapshots in Fossil to avoid it getting
>> corrupt
>
> I think that advice refers to a bug which was fixed in March 2012.

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Thu Nov 27 12:55:40 PST 2014, subscriptions@posteo.eu wrote:
> So, I didn't get too far with my tests, except for what apparently is a
> dead SD card, after about 3 Months uptime doing nothing.
> This is not stellar compared with more than on year uptime with no
> problems for a Linux running on the same Raspberry Pi (other SD card).
>
> Does Plan9 record the access times of files?
> Could this be a reason for the dead SD cards?
> Is there any way to disable recording atimes?
>
> Please note that the Linux "experiment" ran with atime disabled.
> If this is the problem, I could install Plan9 onto a magnetic USB disk
> and only boot from the SD.
>
> What do you folks think?

fossil has no option to disable atime, but kfs does.

now, i've run on rpi-based systems for some time with no issue, and
it would be a mistake i think to assume that all sd cards are created
equal.

- erik

Re: [9fans] running plan9 : an ideal setup?

[David du Colombier]

> fossil has no option to disable atime, but kfs does.

The Fossil "open" command takes the option "-a" to
disable atime.

--
David du Colombier

Re: [9fans] running plan9 : an ideal setup?

[Dante]

Could it be that snapshots induce the same type of wear and tear on the
SD as atime?

--Dante

On 28.11.2014 07:54, David du Colombier wrote:
>> fossil has no option to disable atime, but kfs does.
>
> The Fossil "open" command takes the option "-a" to
> disable atime.
>
> --
> David du Colombier

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

I have to agree with Erik when it comes to SD cards. I've used and
abused many SD cards for years and have never had problems with them.
I could recommend Sandisk Expert Pro that comes with a limited
lifetime warranty (at least in Sweden). They are fast, up to 95 mb/s,
and very reliable according to my experience.

2014-11-28 9:42 GMT+01:00, Dante <subscriptions@posteo.eu>:
> Could it be that snapshots induce the same type of wear and tear on the
> SD as atime?
>
> --Dante
>
> On 28.11.2014 07:54, David du Colombier wrote:
>>> fossil has no option to disable atime, but kfs does.
>>
>> The Fossil "open" command takes the option "-a" to
>> disable atime.
>>
>> --
>> David du Colombier
>
>

Re: [9fans] running plan9 : an ideal setup?

[Dante]

The unfortunate one was a Scandisk Ultra 32GB, which I suppose is of
very good quality.

On 28.11.2014 10:12, Mats Olsson wrote:
> I have to agree with Erik when it comes to SD cards. I've used and
> abused many SD cards for years and have never had problems with them.
> I could recommend Sandisk Expert Pro that comes with a limited
> lifetime warranty (at least in Sweden). They are fast, up to 95 mb/s,
> and very reliable according to my experience.
>
> 2014-11-28 9:42 GMT+01:00, Dante <subscriptions@posteo.eu>:
>> Could it be that snapshots induce the same type of wear and tear on
>> the
>> SD as atime?
>>
>> --Dante
>>
>> On 28.11.2014 07:54, David du Colombier wrote:
>>>> fossil has no option to disable atime, but kfs does.
>>>
>>> The Fossil "open" command takes the option "-a" to
>>> disable atime.
>>>
>>> --
>>> David du Colombier
>>
>>

Re: [9fans] running plan9 : an ideal setup?

[Richard Miller]

> The Fossil "open" command takes the option "-a" to
> disable atime.

... and that's the default on the 9pi distribution image.

term% fossil/conf /dev/sdM0/fossil | grep open
fsys main open -Va

Re: [9fans] running plan9 : an ideal setup?

[Dante]

Check, my SD's fossil also had an -a:
fsys main open -aAV
Thanks, I forgot how I configured it.

But now what did it happen?
We have a Plan9 doing nothing on my desktop.
What does it write to the SD??

On 28.11.2014 10:17, Richard Miller wrote:
>> The Fossil "open" command takes the option "-a" to
>> disable atime.
>
> ... and that's the default on the 9pi distribution image.
>
> term% fossil/conf /dev/sdM0/fossil | grep open
> fsys main open -Va

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Fri Nov 28 01:15:32 PST 2014, 9fans@hamnavoe.com wrote:
> > The Fossil "open" command takes the option "-a" to
> > disable atime.
>
> ... and that's the default on the 9pi distribution image.
>
> term% fossil/conf /dev/sdM0/fossil | grep open
> fsys main open -Va

oops.  my bad.  but...

atta; man fossil | grep -i atime
atta;
atta; man fossilcons | grep -i atime
atta;

- erik

Re: [9fans] running plan9 : an ideal setup?

[David du Colombier]

> oops.  my bad.  but...
>
> atta; man fossil | grep -i atime
> atta;
> atta; man fossilcons | grep -i atime
> atta;

You should have written:

% man fossilcons | grep -i 'access time'
          -a         do not update file access times; primarily to

☺

As far I remember, Geoff added this option when he
implemented support for USB disk boot in 2011.

-- 
David du Colombier

Re: [9fans] running plan9 : an ideal setup?

[Kurt H Maier]

Quoting dante <subscriptions@posteo.eu>:

> - 9Front: comes with the experimental hjfs by default, which got
> corrupt sooner or later on my setup

9front defaults to cwfs64x, not hjfs.

khm

Re: [9fans] running plan9 : an ideal setup?

[dante]

I don't think this applies to the Raspberry Pi.
There is no installer, so the installer defaults are here irrelevant.
For the Pi, a ready-to-boot SD image is provided.


On 18.11.2014 16:42, Kurt H Maier wrote:
> Quoting dante <subscriptions@posteo.eu>:
>
>> - 9Front: comes with the experimental hjfs by default, which got
>> corrupt sooner or later on my setup
>
> 9front defaults to cwfs64x, not hjfs.
>
> khm

Re: [9fans] running plan9 : an ideal setup?

[Aram Hăvărneanu]

If you must use a rpi, you should strive to use it as a terminal, and
like every other Plan 9 terminal it should use the central file server
without local storage.

-- 
Aram Hăvărneanu

Re: [9fans] running plan9 : an ideal setup?

[Richard Miller]

> If you must use a rpi, you should strive to use it as a terminal, and
> like every other Plan 9 terminal it should use the central file server
> without local storage.

That would be my advice too.  As an experiment, I set up a 9picpu using
the SD card as local storage, working mostly as a secondary smtp and imap
server.  After a bit less than a year, the SD card suffered a catastrophic
failure.  When I say catastrophic, I mean I can't find any meaningful data
anywhere in the first 120MB or so of /dev/sdM0/data ... just not-quite-random
looking garbage.

I can't think of any software fault that could wipe out so much of a
disk, with no respect for partition boundaries (the dos partition in
the first 64MB had not been mounted).  But I also know too little about
the internals of SD cards to understand how they fail.  Maybe some
internal logical-to-physical block mapping table went bad?

Anyway, it's just one anecdotal data point, but I wouldn't be happy
running any plan 9 machine with an SD card as the main filesystem.

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

Hi dante!

I would appreciate it a lot if you could send the "clone script" that
you used to clone the 9pi imate to a larger SD card. Thanks
beforehand!

Kind Regards,
Mats

2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>> If you must use a rpi, you should strive to use it as a terminal, and
>> like every other Plan 9 terminal it should use the central file server
>> without local storage.
>
> That would be my advice too.  As an experiment, I set up a 9picpu using
> the SD card as local storage, working mostly as a secondary smtp and imap
> server.  After a bit less than a year, the SD card suffered a catastrophic
> failure.  When I say catastrophic, I mean I can't find any meaningful data
> anywhere in the first 120MB or so of /dev/sdM0/data ... just
> not-quite-random
> looking garbage.
>
> I can't think of any software fault that could wipe out so much of a
> disk, with no respect for partition boundaries (the dos partition in
> the first 64MB had not been mounted).  But I also know too little about
> the internals of SD cards to understand how they fail.  Maybe some
> internal logical-to-physical block mapping table went bad?
>
> Anyway, it's just one anecdotal data point, but I wouldn't be happy
> running any plan 9 machine with an SD card as the main filesystem.
>
>
>

Re: [9fans] running plan9 : an ideal setup?

[dante]

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Hi Mats,

I posted it before; unfortunately the archive doesn't save the attached
files.
Here is the original post: http://9fans.net/archive/2014/08/78.

Please see the attachment for the script.

Cheers,
Dante

On 18.11.2014 22:28, Mats Olsson wrote:
> Hi dante!
>
> I would appreciate it a lot if you could send the "clone script" that
> you used to clone the 9pi imate to a larger SD card. Thanks
> beforehand!
>
> Kind Regards,
> Mats
>
> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>> If you must use a rpi, you should strive to use it as a terminal, and
>>> like every other Plan 9 terminal it should use the central file
>>> server
>>> without local storage.
>>
>> That would be my advice too.  As an experiment, I set up a 9picpu
>> using
>> the SD card as local storage, working mostly as a secondary smtp and
>> imap
>> server.  After a bit less than a year, the SD card suffered a
>> catastrophic
>> failure.  When I say catastrophic, I mean I can't find any meaningful
>> data
>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>> not-quite-random
>> looking garbage.
>>
>> I can't think of any software fault that could wipe out so much of a
>> disk, with no respect for partition boundaries (the dos partition in
>> the first 64MB had not been mounted).  But I also know too little
>> about
>> the internals of SD cards to understand how they fail.  Maybe some
>> internal logical-to-physical block mapping table went bad?
>>
>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>> running any plan 9 machine with an SD card as the main filesystem.
>>
>>
>>

[-- Attachment #2: piclone.txt --]
[-- Type: text/plain, Size: 5510 bytes --]

#!/bin/rc
#
# This program clones a Raspberry Pi Plan9 installation onto another storage device.
# Use a USB adapter for SD cards in order to write another SD card.
# The storage device will be used at its full capacity, in contrast to the downloadable image.
# Moreover, no additional computer is required for the installation.
#
# This program makes some assumptions that are specific to the Raspberry Pi device.
# The only parameter is the name of the destination drive.
# The program will not ask for further input.
#
# NOTES
#
# You can of course use the USB adapter for SD cards to write the downloadable image.
# The bootstrap cannot access a DOS partition embedded into a Plan9 partition (9fat).
# The sd(3) driver cannot serve volumes from a partition table: we use partfs(8) instead.
# Con(1) needs a certain number of empty lines in the input in order to read all server answers.
#

fn check {
	if( ! ~ $1 '' ) {
		echo We encountered an error and must stop here.
		echo Status: $1.
		exit 13
	}
}

if(! test $#* -eq 1) {
	echo Usage: '''piclone sdUY.Z''' creates a Raspberry9 system on sdUY.Z. 
	exit
}

disk=$1
if(! test -d /dev/$disk) {
	echo No such device: $disk.
	exit
}

# Make shure there is no disk configuration left.
echo ........ Null the disk configuration.
dd -if /dev/zero -of /dev/$disk/data -count 1024 >[1=] >[2=]
check $status

# the default MBR without boot code suffices for the Pi.
echo ........ Install MBR.
disk/mbr /dev/$disk/data >[1=] >[2=]
check $status

# We need a real DOS partition.
# The Raspberry Pi boot mechanism cannot cope with the 9FAT partition embedded in the plan9 one.
echo ........ Create DOS partition for booting.
disk/fdisk -b /dev/$disk/data >[1=] >[2=] <<EOF
a p0 0 16
t p0 FAT32
A p0
w
q
EOF
check $status

echo ........ Create a Plan9 partition with default parameters.
disk/fdisk -wa /dev/$disk/data >[1=] >[2=]
check $status

# sd(3) does not serve disk partitions: use partfs(8).
if( ! test -e /dev/$disk/dos ) {
	echo ........ Start partfs to serve partitions.
	disk/partfs -d $disk /dev/$disk/data >[1=] >[2=]
	check $status
}

echo ........ Reconfigure device.
disk/fdisk -p /dev/$disk/data >/dev/$disk/ctl >[2=]
check $status

echo ........ Plan9 partition: install MBR.
disk/mbr /dev/$disk/plan9 >[1=] >[2=]
check $status

echo ........  Plan9 partition: subdivide.
disk/prep -wb -a nvram -a fossil /dev/$disk/plan9 >[1=] >[2=]
check $status

echo ........  Plan9 partition: reconfigure device.
disk/prep -p /dev/$disk/plan9 >/dev/$disk/ctl >[2=]
check $status
echo Partitions on $disk:
cat /dev/$disk/ctl

echo ........  Format DOS partition.
disk/format -d -r2 /dev/$disk/dos >[1=] >[2=]
check $status

echo ........ Format Fossil partition.
fossil/flfmt -y /dev/$disk/fossil >[1=] >[2=]
check $status

if( ! test -e /srv/dos ){
	echo ........ Start DOS server.
	dossrv >[1=] >[2=]
	check $status
}

echo ........ Start server for old Fossil partition.
cat >/env/flproto <<EOF
srv -p fscons.old
srv fossil.old
fsys main config /dev/sdM0/fossil
fsys main open -aAVP
fsys main
EOF
fossil/fossil -c '. /env/flproto' >[1=] >[2=]
check $status

echo ........ Start server for new Fossil partition.
cat >/env/flproto <<EOF
srv -p fscons.new
srv fossil.new
fsys main config /dev/$disk/fossil
fsys main open -aAVWP
fsys main
EOF
fossil/fossil -c '. /env/flproto' #>[1=] >[2=]
check $status

echo ........ Mount old DOS partition.
mount -c /srv/dos /n/dos.old /dev/sdM0/dos >[1=] >[2=]
check $status

echo ........ Mount new DOS partition.
mount -c /srv/dos /n/dos.new /dev/$disk/dos >[1=] >[2=]
check $status

echo ........ Mount old Fossil partition.
mount -c /srv/fossil.old /n/fossil.old >[1=] >[2=]
check $status

echo ........ Mount new Fossil partition.
mount -c /srv/fossil.new /n/fossil.new >[1=] >[2=]
check $status

echo ........ Create users file on new Fossil partition.

# create default
con /srv/fscons.new >[1=] >[2=] <<EOF

create /active/adm adm sys d775
EOF
check $status

# copy
cp -gux /n/fossil.old/adm/users /n/fossil.new/adm/users
check $status

con /srv/fscons.new >[1=] >[2=] <<EOF

users -r /active/adm/users


EOF
check $status

echo ........ Copy boot files.
cp -gux /n/dos.old/* /n/dos.new >[1=] >[2=]
check $status

echo ........ Copy system: please be VERY patient.
disk/mkfs  -a -s /n/fossil.old /sys/lib/sysconfig/proto/allproto  | disk/mkext -u -v -d /n/fossil.new >[2=1]  | tee /tmp/xxx
echo ........ Status: $status.

echo ........ Unmount old DOS partition.
unmount /n/dos.old >[1=] >[2=]
check $status

echo ........ Unmount new DOS partition.
unmount /n/dos.new >[1=] >[2=]
check $status

echo ........ Unmount old Fossil partition.
unmount /n/fossil.old >[1=] >[2=]
check $status

echo ........ Stop server for old Fossil partition.
con /srv/fscons.old >[1=] >[2=] <<EOF
srv -d fossil.old
srv -d fscons.old
EOF
check $status

echo ........ Unmount new Fossil partition.
unmount /n/fossil.new >[1=] >[2=]
check $status

echo ........ Stop server for new Fossil partition.
con /srv/fscons.new >[1=] >[2=] <<EOF
srv -d fossil.new
srv -d fscons.new
EOF
check $status

echo ......... Kill fossil.
kill fossil | rc >[1=] >[2=]
rm /srv/fossil.old >[1=] >[2=]
rm /srv/fscons.old >[1=] >[2=]
rm /srv/fossil.new >[1=] >[2=]
rm /srv/fscons.new >[1=] >[2=]

echo ........ Write persistent Fossil configuration.
fossil/conf -w /dev/$disk/fossil >[1=] >[2=]  <<EOF
fsys main config
fsys main open -aAV
fsys main snaptime -a none -s 60 -t 172800
fsys main
users -r /active/adm/users
EOF
check $status

echo ........ DONE

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

Hi dante!

Thanks a lot! Now I have saved the script.

Kind regards,
Mats

2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
> Hi Mats,
>
> I posted it before; unfortunately the archive doesn't save the attached
> files.
> Here is the original post: http://9fans.net/archive/2014/08/78.
>
> Please see the attachment for the script.
>
> Cheers,
> Dante
>
> On 18.11.2014 22:28, Mats Olsson wrote:
>> Hi dante!
>>
>> I would appreciate it a lot if you could send the "clone script" that
>> you used to clone the 9pi imate to a larger SD card. Thanks
>> beforehand!
>>
>> Kind Regards,
>> Mats
>>
>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>> If you must use a rpi, you should strive to use it as a terminal, and
>>>> like every other Plan 9 terminal it should use the central file
>>>> server
>>>> without local storage.
>>>
>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>> using
>>> the SD card as local storage, working mostly as a secondary smtp and
>>> imap
>>> server.  After a bit less than a year, the SD card suffered a
>>> catastrophic
>>> failure.  When I say catastrophic, I mean I can't find any meaningful
>>> data
>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>> not-quite-random
>>> looking garbage.
>>>
>>> I can't think of any software fault that could wipe out so much of a
>>> disk, with no respect for partition boundaries (the dos partition in
>>> the first 64MB had not been mounted).  But I also know too little
>>> about
>>> the internals of SD cards to understand how they fail.  Maybe some
>>> internal logical-to-physical block mapping table went bad?
>>>
>>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>>> running any plan 9 machine with an SD card as the main filesystem.
>>>
>>>
>>>

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

Hi dante!

I copied your piclone script in Plan 9 but even though I've been
digging I can't find out how to get the name of the SD card attached
to the pi on which I want to clone my setup on. So, easily put, what
command do I use to get to know that? So I wonder how to get the
device name of the clean SD in the USB card adapter. In your post
first mentioning the script you wrote: "If the device is recognized as
"sdUXX", call "piclone sdUXX". Well that is what I want to find out.
If I get that I'm ready to "rock and roll".

Kind Greetings,
Mats

2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
> Hi Mats,
>
> I posted it before; unfortunately the archive doesn't save the attached
> files.
> Here is the original post: http://9fans.net/archive/2014/08/78.
>
> Please see the attachment for the script.
>
> Cheers,
> Dante
>
> On 18.11.2014 22:28, Mats Olsson wrote:
>> Hi dante!
>>
>> I would appreciate it a lot if you could send the "clone script" that
>> you used to clone the 9pi imate to a larger SD card. Thanks
>> beforehand!
>>
>> Kind Regards,
>> Mats
>>
>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>> If you must use a rpi, you should strive to use it as a terminal, and
>>>> like every other Plan 9 terminal it should use the central file
>>>> server
>>>> without local storage.
>>>
>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>> using
>>> the SD card as local storage, working mostly as a secondary smtp and
>>> imap
>>> server.  After a bit less than a year, the SD card suffered a
>>> catastrophic
>>> failure.  When I say catastrophic, I mean I can't find any meaningful
>>> data
>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>> not-quite-random
>>> looking garbage.
>>>
>>> I can't think of any software fault that could wipe out so much of a
>>> disk, with no respect for partition boundaries (the dos partition in
>>> the first 64MB had not been mounted).  But I also know too little
>>> about
>>> the internals of SD cards to understand how they fail.  Maybe some
>>> internal logical-to-physical block mapping table went bad?
>>>
>>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>>> running any plan 9 machine with an SD card as the main filesystem.
>>>
>>>
>>>

Re: [9fans] running plan9 : an ideal setup?

[Dante]

Hi Mats,

Look in the /dev directory (ls /dev).
If you only have the boot device and an additional USB drive (in your
case, an USB-to-SD adapter),
the boot device shall be /dev/sdM0 and
the USB/SD device shall be /dev/sdU0.0

Kind Regards,
Dante

On 26.11.2014 18:16, Mats Olsson wrote:
> Hi dante!
>
> I copied your piclone script in Plan 9 but even though I've been
> digging I can't find out how to get the name of the SD card attached
> to the pi on which I want to clone my setup on. So, easily put, what
> command do I use to get to know that? So I wonder how to get the
> device name of the clean SD in the USB card adapter. In your post
> first mentioning the script you wrote: "If the device is recognized as
> "sdUXX", call "piclone sdUXX". Well that is what I want to find out.
> If I get that I'm ready to "rock and roll".
>
> Kind Greetings,
> Mats
>
> 2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
>> Hi Mats,
>>
>> I posted it before; unfortunately the archive doesn't save the
>> attached
>> files.
>> Here is the original post: http://9fans.net/archive/2014/08/78.
>>
>> Please see the attachment for the script.
>>
>> Cheers,
>> Dante
>>
>> On 18.11.2014 22:28, Mats Olsson wrote:
>>> Hi dante!
>>>
>>> I would appreciate it a lot if you could send the "clone script" that
>>> you used to clone the 9pi imate to a larger SD card. Thanks
>>> beforehand!
>>>
>>> Kind Regards,
>>> Mats
>>>
>>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>>> If you must use a rpi, you should strive to use it as a terminal,
>>>>> and
>>>>> like every other Plan 9 terminal it should use the central file
>>>>> server
>>>>> without local storage.
>>>>
>>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>>> using
>>>> the SD card as local storage, working mostly as a secondary smtp and
>>>> imap
>>>> server.  After a bit less than a year, the SD card suffered a
>>>> catastrophic
>>>> failure.  When I say catastrophic, I mean I can't find any
>>>> meaningful
>>>> data
>>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>>> not-quite-random
>>>> looking garbage.
>>>>
>>>> I can't think of any software fault that could wipe out so much of a
>>>> disk, with no respect for partition boundaries (the dos partition in
>>>> the first 64MB had not been mounted).  But I also know too little
>>>> about
>>>> the internals of SD cards to understand how they fail.  Maybe some
>>>> internal logical-to-physical block mapping table went bad?
>>>>
>>>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>>>> running any plan 9 machine with an SD card as the main filesystem.
>>>>
>>>>
>>>>

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

Hi!

So "piclone sdU0.0" would be right? I have the script in
/usr/glenda/home does that matter?

Yours Sincerely,
Mats


2014-11-26 18:41 GMT+01:00, Dante <subscriptions@posteo.eu>:
> Hi Mats,
>
> Look in the /dev directory (ls /dev).
> If you only have the boot device and an additional USB drive (in your
> case, an USB-to-SD adapter),
> the boot device shall be /dev/sdM0 and
> the USB/SD device shall be /dev/sdU0.0
>
> Kind Regards,
> Dante
>
> On 26.11.2014 18:16, Mats Olsson wrote:
>> Hi dante!
>>
>> I copied your piclone script in Plan 9 but even though I've been
>> digging I can't find out how to get the name of the SD card attached
>> to the pi on which I want to clone my setup on. So, easily put, what
>> command do I use to get to know that? So I wonder how to get the
>> device name of the clean SD in the USB card adapter. In your post
>> first mentioning the script you wrote: "If the device is recognized as
>> "sdUXX", call "piclone sdUXX". Well that is what I want to find out.
>> If I get that I'm ready to "rock and roll".
>>
>> Kind Greetings,
>> Mats
>>
>> 2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
>>> Hi Mats,
>>>
>>> I posted it before; unfortunately the archive doesn't save the
>>> attached
>>> files.
>>> Here is the original post: http://9fans.net/archive/2014/08/78.
>>>
>>> Please see the attachment for the script.
>>>
>>> Cheers,
>>> Dante
>>>
>>> On 18.11.2014 22:28, Mats Olsson wrote:
>>>> Hi dante!
>>>>
>>>> I would appreciate it a lot if you could send the "clone script" that
>>>> you used to clone the 9pi imate to a larger SD card. Thanks
>>>> beforehand!
>>>>
>>>> Kind Regards,
>>>> Mats
>>>>
>>>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>>>> If you must use a rpi, you should strive to use it as a terminal,
>>>>>> and
>>>>>> like every other Plan 9 terminal it should use the central file
>>>>>> server
>>>>>> without local storage.
>>>>>
>>>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>>>> using
>>>>> the SD card as local storage, working mostly as a secondary smtp and
>>>>> imap
>>>>> server.  After a bit less than a year, the SD card suffered a
>>>>> catastrophic
>>>>> failure.  When I say catastrophic, I mean I can't find any
>>>>> meaningful
>>>>> data
>>>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>>>> not-quite-random
>>>>> looking garbage.
>>>>>
>>>>> I can't think of any software fault that could wipe out so much of a
>>>>> disk, with no respect for partition boundaries (the dos partition in
>>>>> the first 64MB had not been mounted).  But I also know too little
>>>>> about
>>>>> the internals of SD cards to understand how they fail.  Maybe some
>>>>> internal logical-to-physical block mapping table went bad?
>>>>>
>>>>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>>>>> running any plan 9 machine with an SD card as the main filesystem.
>>>>>
>>>>>
>>>>>
>
>

Re: [9fans] running plan9 : an ideal setup?

[Mats Olsson]

Hi dante!

In answer to my own question: DONE. Thanks a lot!

Kind Greetings,
Mats

2014-11-26 18:56 GMT+01:00, Mats Olsson <plan9.meo@gmail.com>:
> Hi!
>
> So "piclone sdU0.0" would be right? I have the script in
> /usr/glenda/home does that matter?
>
> Yours Sincerely,
> Mats
>
>
> 2014-11-26 18:41 GMT+01:00, Dante <subscriptions@posteo.eu>:
>> Hi Mats,
>>
>> Look in the /dev directory (ls /dev).
>> If you only have the boot device and an additional USB drive (in your
>> case, an USB-to-SD adapter),
>> the boot device shall be /dev/sdM0 and
>> the USB/SD device shall be /dev/sdU0.0
>>
>> Kind Regards,
>> Dante
>>
>> On 26.11.2014 18:16, Mats Olsson wrote:
>>> Hi dante!
>>>
>>> I copied your piclone script in Plan 9 but even though I've been
>>> digging I can't find out how to get the name of the SD card attached
>>> to the pi on which I want to clone my setup on. So, easily put, what
>>> command do I use to get to know that? So I wonder how to get the
>>> device name of the clean SD in the USB card adapter. In your post
>>> first mentioning the script you wrote: "If the device is recognized as
>>> "sdUXX", call "piclone sdUXX". Well that is what I want to find out.
>>> If I get that I'm ready to "rock and roll".
>>>
>>> Kind Greetings,
>>> Mats
>>>
>>> 2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
>>>> Hi Mats,
>>>>
>>>> I posted it before; unfortunately the archive doesn't save the
>>>> attached
>>>> files.
>>>> Here is the original post: http://9fans.net/archive/2014/08/78.
>>>>
>>>> Please see the attachment for the script.
>>>>
>>>> Cheers,
>>>> Dante
>>>>
>>>> On 18.11.2014 22:28, Mats Olsson wrote:
>>>>> Hi dante!
>>>>>
>>>>> I would appreciate it a lot if you could send the "clone script" that
>>>>> you used to clone the 9pi imate to a larger SD card. Thanks
>>>>> beforehand!
>>>>>
>>>>> Kind Regards,
>>>>> Mats
>>>>>
>>>>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>>>>> If you must use a rpi, you should strive to use it as a terminal,
>>>>>>> and
>>>>>>> like every other Plan 9 terminal it should use the central file
>>>>>>> server
>>>>>>> without local storage.
>>>>>>
>>>>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>>>>> using
>>>>>> the SD card as local storage, working mostly as a secondary smtp and
>>>>>> imap
>>>>>> server.  After a bit less than a year, the SD card suffered a
>>>>>> catastrophic
>>>>>> failure.  When I say catastrophic, I mean I can't find any
>>>>>> meaningful
>>>>>> data
>>>>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>>>>> not-quite-random
>>>>>> looking garbage.
>>>>>>
>>>>>> I can't think of any software fault that could wipe out so much of a
>>>>>> disk, with no respect for partition boundaries (the dos partition in
>>>>>> the first 64MB had not been mounted).  But I also know too little
>>>>>> about
>>>>>> the internals of SD cards to understand how they fail.  Maybe some
>>>>>> internal logical-to-physical block mapping table went bad?
>>>>>>
>>>>>> Anyway, it's just one anecdotal data point, but I wouldn't be happy
>>>>>> running any plan 9 machine with an SD card as the main filesystem.
>>>>>>
>>>>>>
>>>>>>
>>
>>
>

Re: [9fans] running plan9 : an ideal setup?

[Dante]

Cool, first tester :-).
Thanks, Mats!

-- Dante

On 26.11.2014 19:16, Mats Olsson wrote:
> Hi dante!
>
> In answer to my own question: DONE. Thanks a lot!
>
> Kind Greetings,
> Mats
>
> 2014-11-26 18:56 GMT+01:00, Mats Olsson <plan9.meo@gmail.com>:
>> Hi!
>>
>> So "piclone sdU0.0" would be right? I have the script in
>> /usr/glenda/home does that matter?
>>
>> Yours Sincerely,
>> Mats
>>
>>
>> 2014-11-26 18:41 GMT+01:00, Dante <subscriptions@posteo.eu>:
>>> Hi Mats,
>>>
>>> Look in the /dev directory (ls /dev).
>>> If you only have the boot device and an additional USB drive (in your
>>> case, an USB-to-SD adapter),
>>> the boot device shall be /dev/sdM0 and
>>> the USB/SD device shall be /dev/sdU0.0
>>>
>>> Kind Regards,
>>> Dante
>>>
>>> On 26.11.2014 18:16, Mats Olsson wrote:
>>>> Hi dante!
>>>>
>>>> I copied your piclone script in Plan 9 but even though I've been
>>>> digging I can't find out how to get the name of the SD card attached
>>>> to the pi on which I want to clone my setup on. So, easily put, what
>>>> command do I use to get to know that? So I wonder how to get the
>>>> device name of the clean SD in the USB card adapter. In your post
>>>> first mentioning the script you wrote: "If the device is recognized
>>>> as
>>>> "sdUXX", call "piclone sdUXX". Well that is what I want to find out.
>>>> If I get that I'm ready to "rock and roll".
>>>>
>>>> Kind Greetings,
>>>> Mats
>>>>
>>>> 2014-11-18 23:09 GMT+01:00, dante <subscriptions@posteo.eu>:
>>>>> Hi Mats,
>>>>>
>>>>> I posted it before; unfortunately the archive doesn't save the
>>>>> attached
>>>>> files.
>>>>> Here is the original post: http://9fans.net/archive/2014/08/78.
>>>>>
>>>>> Please see the attachment for the script.
>>>>>
>>>>> Cheers,
>>>>> Dante
>>>>>
>>>>> On 18.11.2014 22:28, Mats Olsson wrote:
>>>>>> Hi dante!
>>>>>>
>>>>>> I would appreciate it a lot if you could send the "clone script"
>>>>>> that
>>>>>> you used to clone the 9pi imate to a larger SD card. Thanks
>>>>>> beforehand!
>>>>>>
>>>>>> Kind Regards,
>>>>>> Mats
>>>>>>
>>>>>> 2014-11-18 21:29 GMT+01:00, Richard Miller <9fans@hamnavoe.com>:
>>>>>>>> If you must use a rpi, you should strive to use it as a
>>>>>>>> terminal,
>>>>>>>> and
>>>>>>>> like every other Plan 9 terminal it should use the central file
>>>>>>>> server
>>>>>>>> without local storage.
>>>>>>>
>>>>>>> That would be my advice too.  As an experiment, I set up a 9picpu
>>>>>>> using
>>>>>>> the SD card as local storage, working mostly as a secondary smtp
>>>>>>> and
>>>>>>> imap
>>>>>>> server.  After a bit less than a year, the SD card suffered a
>>>>>>> catastrophic
>>>>>>> failure.  When I say catastrophic, I mean I can't find any
>>>>>>> meaningful
>>>>>>> data
>>>>>>> anywhere in the first 120MB or so of /dev/sdM0/data ... just
>>>>>>> not-quite-random
>>>>>>> looking garbage.
>>>>>>>
>>>>>>> I can't think of any software fault that could wipe out so much
>>>>>>> of a
>>>>>>> disk, with no respect for partition boundaries (the dos partition
>>>>>>> in
>>>>>>> the first 64MB had not been mounted).  But I also know too little
>>>>>>> about
>>>>>>> the internals of SD cards to understand how they fail.  Maybe
>>>>>>> some
>>>>>>> internal logical-to-physical block mapping table went bad?
>>>>>>>
>>>>>>> Anyway, it's just one anecdotal data point, but I wouldn't be
>>>>>>> happy
>>>>>>> running any plan 9 machine with an SD card as the main
>>>>>>> filesystem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>
>>

Re: [9fans] running plan9 : an ideal setup?

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for
boot loading and the nvram partition. setting up the nvram without a
console is tricky; i thought i'd mention it here in case others run into it.

1. using the existing 9pi SD image, edit config.txt and set 'kernel' to
'uboot.img'.
2. on the auth+fs, build a bcm kernel with nvram partition in the kernel
(i.e. /boot/nvram)
3. create the /cfg/pxe/<MAC> for the box and initially set the nvram
parameter to /boot/nvram.
4. after the first boot,  cpu into the rpi and do the auth/wrkey dance with
'#S/sdM0/nvram'
5. reset the the nvram in /cfg/pxe/<MAC> to #S/sdM0/nvram
6. rebuild the bcm kernel without the nvram
7. reboot the rpi

i've been contemplating making my auth server a 9picpu booting from local,
but SD reliability is the drawback.


On Tue, Nov 18, 2014 at 12:29 PM, Richard Miller <9fans@hamnavoe.com> wrote:

> > If you must use a rpi, you should strive to use it as a terminal, and
> > like every other Plan 9 terminal it should use the central file server
> > without local storage.
>
> That would be my advice too.  As an experiment, I set up a 9picpu using
> the SD card as local storage, working mostly as a secondary smtp and imap
> server.  After a bit less than a year, the SD card suffered a catastrophic
> failure.  When I say catastrophic, I mean I can't find any meaningful data
> anywhere in the first 120MB or so of /dev/sdM0/data ... just
> not-quite-random
> looking garbage.
>
> I can't think of any software fault that could wipe out so much of a
> disk, with no respect for partition boundaries (the dos partition in
> the first 64MB had not been mounted).  But I also know too little about
> the internals of SD cards to understand how they fail.  Maybe some
> internal logical-to-physical block mapping table went bad?
>
> Anyway, it's just one anecdotal data point, but I wouldn't be happy
> running any plan 9 machine with an SD card as the main filesystem.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2558 bytes --]

Re: [9fans] running plan9 : an ideal setup?

[Steve Simon]

> i've been contemplating making my auth server a 9picpu booting from local,
> but SD reliability is the drawback.

I believe the pi will run with an external flash or hard drive, abet slowly
and using a powered USB hub.

you could boot the kernel from the sd card but mount the external
device everywhere you need to write things, like /sys/log and /adm/keys

This would give you the speed of flash but the reliability of a magnetic
disk or flash drive.

You could even use multiple external flash drives with fs(3).

Just some random ideas.

-Steve

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Tue Nov 18 17:10:59 EST 2014, skip.tavakkolian@gmail.com wrote:

> i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for
> boot loading and the nvram partition. setting up the nvram without a
> console is tricky; i thought i'd mention it here in case others run into it.

why not use cec(1) from 9atom?  this completely solves the console issue
without requiring any expensive or uncommon hardware.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

i'm a bit paranoid about ether frames jumping the switch somehow, but i
guess that's as likely as local snooping while tftping the boot image that
has the nvram with creds.

On Tue, Nov 18, 2014 at 5:57 PM, erik quanstrom <quanstro@quanstro.net>
wrote:

> On Tue Nov 18 17:10:59 EST 2014, skip.tavakkolian@gmail.com wrote:
>
> > i have two 9picpu's. they tftp-boot from the auth+fs. the SD is used for
> > boot loading and the nvram partition. setting up the nvram without a
> > console is tricky; i thought i'd mention it here in case others run into
> it.
>
> why not use cec(1) from 9atom?  this completely solves the console issue
> without requiring any expensive or uncommon hardware.
>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

Re: [9fans] running plan9 : an ideal setup?

[lucio]

> i'm a bit paranoid about ether frames jumping the switch somehow, but i
> guess that's as likely as local snooping while tftping the boot image that
> has the nvram with creds.

Well, if you're paranoid, then being able to "write" arbitrary data to
the console is more serious than intercepting a password, at least on
the surface.

Lucio.

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Wed Nov 19 01:07:43 EST 2014, lucio@proxima.alt.za wrote:
> > i'm a bit paranoid about ether frames jumping the switch somehow, but i
> > guess that's as likely as local snooping while tftping the boot image that
> > has the nvram with creds.
>
> Well, if you're paranoid, then being able to "write" arbitrary data to
> the console is more serious than intercepting a password, at least on
> the surface.

i'd encourage folks to at least try cec before assuming things about how
it works.

by the way, at one point i had a hacked up kernel which allowed me to
mount a file server over the cec protocol.  quite a bit like nonet.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Aram Hăvărneanu]

On Wed, Nov 19, 2014 at 3:36 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> by the way, at one point i had a hacked up kernel which allowed me to
> mount a file server over the cec protocol.

In what situation would this be useful?

-- 
Aram Hăvărneanu

Re: [9fans] running plan9 : an ideal setup?

[Anthony Sorace]

I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist.

Also, I really want to exercise the cross-network parts of Plan 9.

> On Nov 19, 2014, at 10:34 , Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> 
> On Wed, Nov 19, 2014 at 3:36 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> by the way, at one point i had a hacked up kernel which allowed me to
>> mount a file server over the cec protocol.
> 
> In what situation would this be useful?
> 
> -- 
> Aram Hăvărneanu

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Thu Nov 20 01:02:53 EST 2014, a@9srv.net wrote:
> I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist.

anthony, i'm sure your fingers just got crossed up, but i think you ment
computers are fast enough that the overhead doesn't matter.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Anthony Sorace]

Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course.

> On Nov 20, 2014, at 9:37 , erik quanstrom <quanstro@quanstro.net> wrote:
> 
> On Thu Nov 20 01:02:53 EST 2014, a@9srv.net wrote:
>> I can't speak for Erik's cec-as-nonet setup specifically, but I've wanted nonet (or an equivalent) many, many times. Networks are fast enough that tcp/ip overhead isn't really something that hurts in most cases, but it does exist.
> 
> anthony, i'm sure your fingers just got crossed up, but i think you ment
> computers are fast enough that the overhead doesn't matter.
> 
> - erik

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Thu Nov 20 13:44:04 EST 2014, a@9srv.net wrote:
> Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course.

this is not correct.  tcp doesn't help at all when the wire is fast (short, fat).  it's the classic tradeoff of cpu
for (networking) performance.  the wire being fast enough is an argument against using tcp,
not for it.

so really, it's the gobs of cpu we currently have that make tcp not an issue, not the gobs of bandwidth.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Anthony Sorace]

On Nov 21, 2014, at 9:34 , erik quanstrom <quanstro@quanstro.net> wrote:
> 
> this is not correct.  tcp doesn't help at all when the wire is fast (short, fat).  it's the classic tradeoff of cpu
> for (networking) performance.  the wire being fast enough is an argument against using tcp,
> not for it.

I don't think what we're saying is incompatible. I'm not saying that tcp helps, or doesn't have overhead, with fast pipes. I'm saying that the pipes are fast enough that in most use cases, at least for me, the pipe is fast enough that ((wire speed) - (tcp/ip overhead)) is still plenty fast.

Re: [9fans] running plan9 : an ideal setup?

[Bakul Shah]

This paper is well worth reading:
http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20Processing%20Overhead.pdf

While the traditional BSD implementation uses mbufs that complicate things, actual tcp processing can be done quite cheaply.

> On Nov 21, 2014, at 6:34 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> 
>> On Thu Nov 20 13:44:04 EST 2014, a@9srv.net wrote:
>> Both. I agree with what you're saying about the computers, but I was thinking of the fact that the wire speed is fast enough in most cases that the tcp/ip overhead doesn't impact things noticeably for most uses. There are outliers in both cases, of course.
> 
> this is not correct.  tcp doesn't help at all when the wire is fast (short, fat).  it's the classic tradeoff of cpu
> for (networking) performance.  the wire being fast enough is an argument against using tcp,
> not for it.
> 
> so really, it's the gobs of cpu we currently have that make tcp not an issue, not the gobs of bandwidth.
> 
> - erik
> 

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Fri Nov 21 12:31:13 EST 2014, bakul@bitblocks.com wrote:
> This paper is well worth reading:
> http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20Processing%20Overhead.pdf
>
> While the traditional BSD implementation uses mbufs that complicate things, actual tcp processing can be done quite cheaply.

- ignores tcp checksum -- it alone will take a couple cycles per byte.
- ignores locking
	and i believe they've used the BKL to avoid locking any data structures, otherwise
	how could they process ip in 61 instructions?  actually there's proof of this in the
	timer instruction count -- 17.  that's not enough to acquire a lock.
- asserts that 300 instructions of x86 code -> 400 instructions of risc code, conservatively
	absolutely not if one of them is rep; movb  (which they appear to use)

in short, i see signs that this paper is not realistic.

furthermore, this sunny picture assumes an environment where tcp isn't giving any
benefit.  if you're not retransmitting a bit, you're not getting anything out of tcp.
i think this was the original point.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Bakul Shah]

On Sat, 22 Nov 2014 13:06:15 EST erik quanstrom <quanstro@quanstro.net> wrote:
> On Fri Nov 21 12:31:13 EST 2014, bakul@bitblocks.com wrote:
> > This paper is well worth reading:
> > http://groups.csail.mit.edu/ana/Publications/PubPDFs/1988Analysis%20TCP%20P
> rocessing%20Overhead.pdf
> >
> > While the traditional BSD implementation uses mbufs that complicate things,
>  actual tcp processing can be done quite cheaply.
>
> - ignores tcp checksum -- it alone will take a couple cycles per byte.

They factored out path common to all IP, to measure TCP's overhead.
tcp checksum is basically IP checksum.

> - ignores locking
> 	and i believe they've used the BKL to avoid locking any data structures
> , otherwise
> 	how could they process ip in 61 instructions?  actually there's proof o
> f this in the
> 	timer instruction count -- 17.  that's not enough to acquire a lock.

Again, matching an incoming packet to find its PCB is common to all so
they didn't put this in tcp overhead computation.

As long as you run IP, you pay the other costs for any protocol.

> - asserts that 300 instructions of x86 code -> 400 instructions of risc code,
>  conservatively
> 	absolutely not if one of them is rep; movb  (which they appear to use)

Can't speak to this.

> in short, i see signs that this paper is not realistic.

I think it is very realistic.  They modified standard bsd
stack (I don't know its present state but back when I worked
on it, it needed to be simplified quite a bit).

> furthermore, this sunny picture assumes an environment where tcp isn't giving
>  any
> benefit.  if you're not retransmitting a bit, you're not getting anything out
>  of tcp.

If you use TCP you benefit from its near universality, dealing
with long fat pipes, bandwidth adjustment, selective ack etc.

My point was that even with all its complexity, tcp's
processing overhead can be fairly low for the common case.

I haven't looked into why on the RPi plan9's tcp performance
is about 30-40% of that on linux (which works near wire speed).
For the local case it doesn't matter much in any case.

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

> I think it is very realistic.  They modified standard bsd
> stack (I don't know its present state but back when I worked
> on it, it needed to be simplified quite a bit).

i think a no lock tcp stack from 1990 hacked to be even less sophisticated is anything
but realistic.  it's pure fantasy that one can avoid proper locking today.

and at 10gbe packet rates even 400 instructions per packet (* 1.5 for the reply)
is not a trivial expense.

> I haven't looked into why on the RPi plan9's tcp performance
> is about 30-40% of that on linux (which works near wire speed).
> For the local case it doesn't matter much in any case.

(a) allocb() relies on deathly slow malloc; cf. qallocb in 9atom, which upps performance quite a bit
(b) usb is not as fast,
(c) send and recieve in plan 9's tcp are not as decoupled as they could be,
this leads to latency in sending after the window opens, or latency in opening
the window.

- erik

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

> > I haven't looked into why on the RPi plan9's tcp performance
> > is about 30-40% of that on linux (which works near wire speed).
> > For the local case it doesn't matter much in any case.
>
> (a) allocb() relies on deathly slow malloc; cf. qallocb in 9atom, which upps performance quite a bit
> (b) usb is not as fast,
> (c) send and recieve in plan 9's tcp are not as decoupled as they could be,
> this leads to latency in sending after the window opens, or latency in opening
> the window.

we did get a lot of performance out of a proper NewReno implentation, which
happened after the original rpi port.

a review of changes in sources from the original work didn't turn up any noteworthy
changes, but then again just reviewing the source code isn't all that effective.  :-)

- erik

Re: [9fans] running plan9 : an ideal setup?

[Anthony Sorace]

On Nov 25, 2014, at 1:59 , Bakul Shah <bakul@bitblocks.com> wrote:

> As long as you run IP, you pay the other costs for any protocol.

But there's plenty of cases where you don't need even that. See AOE, or nonet from very early Plan 9. I'd like that back.

> If you use TCP you benefit from its near universality, dealing
> with long fat pipes, bandwidth adjustment, selective ack etc.

Those are all valid reasons to have a tcp/ip stack. But what I (and I believe Erik) say is that there's cases where that doesn't matter, and it would be nice to have an alternative in those cases. I no that IL makes a noticeable (if tiny) difference on my local network; I bet nonet would be a marginally greater difference.

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Tue Nov 25 08:52:33 EST 2014, a@9srv.net wrote:
> On Nov 25, 2014, at 1:59 , Bakul Shah <bakul@bitblocks.com> wrote:
>
> > As long as you run IP, you pay the other costs for any protocol.
>
> But there's plenty of cases where you don't need even that. See AOE, or nonet from very early Plan 9. I'd like that back.

and in any event, processor cycles are (relatively) not important.  synchronization latency
and memory latency dominate.  there's more of that for tcp, and it's not accounted for.

- erik

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Wed Nov 19 00:36:36 EST 2014, skip.tavakkolian@gmail.com wrote:

> i'm a bit paranoid about ether frames jumping the switch somehow, but i
> guess that's as likely as local snooping while tftping the boot image that
> has the nvram with creds.

your switch is really broken if it forwards ethernet frames (no tcp, no ip).
off the local segment.  it's already a security concern.

i've never seen this happen.

- erik

Re: [9fans] running plan9 : an ideal setup?

[Bakul Shah]

On Tue, 18 Nov 2014 20:29:30 GMT Richard Miller <9fans@hamnavoe.com> wrote:
>
> I can't think of any software fault that could wipe out so much of a
> disk, with no respect for partition boundaries (the dos partition in
> the first 64MB had not been mounted).  But I also know too little about
> the internals of SD cards to understand how they fail.  Maybe some
> internal logical-to-physical block mapping table went bad?

One possibility:
Many SD cards don't implement wear leveling. Without it, if
the system is hitting some speicific blocks over and over
again, the card will become unusable fast. I was using a $10
USB thumb drive as a boot disk for my FreeBSD based fileserver
and forgot to mount it readonly (and unix syncs every 30
seconds to all r/w fs).  It was toast within a year. On the
raspi I've had good experience with the better quality SanDisk
SD cards.  I even have venti running on one for the past 6
months -- as an experiment, so I don't care if the card dies!

Re: [9fans] running plan9 : an ideal setup?

[Tom Ivar Helbekkmo]

Richard Miller <9fans@hamnavoe.com> writes:

> After a bit less than a year, the SD card suffered a catastrophic
> failure.  When I say catastrophic, I mean I can't find any meaningful
> data anywhere in the first 120MB or so of /dev/sdM0/data ... just
> not-quite-random looking garbage.

Could have been just the normal "SD card used up" situation.  They don't
last forever, and to get a reasonable life time you have to a) not buy
too cheap, and b) not write to it more than you have to.  Under Unix,
point b means mounting with noatime and nodiratime options.

Some specifics here: http://en.wikipedia.org/wiki/Wear_leveling

-tih
--
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong.  -Richard Feynman

Re: [9fans] running plan9 : an ideal setup?

[Harri Haataja]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On 19 Nov 2014 23:54, "Tom Ivar Helbekkmo" <tih@hamartun.priv.no> wrote:
> Richard Miller <9fans@hamnavoe.com> writes:
>
> > After a bit less than a year, the SD card suffered a catastrophic
> > failure.  When I say catastrophic, I mean I can't find any meaningful
> > data anywhere in the first 120MB or so of /dev/sdM0/data ... just
> > not-quite-random looking garbage.
>
> Could have been just the normal "SD card used up" situation.  They don't
> last forever, and to get a reasonable life time you have to a) not buy
> too cheap, and b) not write to it more than you have to.  Under Unix,
> point b means mounting with noatime and nodiratime options.
>
> Some specifics here: http://en.wikipedia.org/wiki/Wear_leveling

Raspi in particular also seems to be very sensitive to power quality. Often
the symptom of overloaded power supply is a crash and an unbootable SD card.

Frequent backups of the card are probably a good idea in any case.

[-- Attachment #2: Type: text/html, Size: 1308 bytes --]

Re: [9fans] running plan9 : an ideal setup?

[erik quanstrom]

On Tue Nov 18 12:03:04 EST 2014, aram.h@mgk.ro wrote:
> If you must use a rpi, you should strive to use it as a terminal, and
> like every other Plan 9 terminal it should use the central file server
> without local storage.

+1.  if i understand correctly, the labs used physical security for the authentication
server, and it booted off a local fs.  while this is a very tidy idea, i think reality
booges things up, and it doesn't really work out.

- erik

Re: [9fans] running plan9 : an ideal setup?

[lucio]

> i think reality
> booges things up, and it doesn't really work out.

More specifically, an auth server can provide very tight security, but
where such is not needed, it is too tempting to run services on it as
it is the most convenient place to do it from.  Once you have enough
power behind the auth server to run one service, you no longer have
the security benefits.  Discipline is demanded and the price is a bit
steep.

I know because for a long time I ran an auth server on what would be
considered a toy even back then, but once it failed, it was never
re-deployed.

Reading some of the scary stuff the NSA seems to be getting up to,
though, it is nice to know that your border equipment (not your
private auth server) is unlikely ever to be "owned" by NSA spooks.

Lucio.

PS: I do have a dedicated auth server, but electricity supply
constraints cause it to stay off most of the time, leading to bit rot.
The unreliabilty of the Internet link means it cannot act as auth
server for my public equipment, so that problem needs to be solved
first.  Running it off a photovoltaic/battery source is definitely the
next plan.


-------------------------------------------------------------------------------------
This email has been scanned by the MxScan Email Security System.
-------------------------------------------------------------------------------------

Re: [9fans] running plan9 : an ideal setup?

[Steve Simon]

> - Plan9: don't enable periodic snapshots in Fossil to avoid it getting  corrupt

This is no longer true, this long standing bug was fixed about a year ago.

Can you remember where you saw the documentation saying snapshots where
still broken?

-Steve

Re: [9fans] running plan9 : an ideal setup?

[dante]

Dear Steve,

I never knew that there was a known bug there: got my frist Plan9 this
summer.
I enabled snapshots on my Pi this summer and got a corrupt file system
within hours.
As I promised Richard, I'll try to reproduce the issue and post a bug
report to this list.
This looks to me as a regression (or some other problem with my system).

Kind Regards,
Dante

On 19.11.2014 10:40, Steve Simon wrote:
>> - Plan9: don't enable periodic snapshots in Fossil to avoid it getting
>>  corrupt
>
> This is no longer true, this long standing bug was fixed about a year
> ago.
>
> Can you remember where you saw the documentation saying snapshots where
> still broken?
>
> -Steve

Re: [9fans] running plan9 : an ideal setup?

[Steve Simon]

> I never knew that there was a known bug there:
> got my frist Plan9 this  summer.
> I enabled snapshots on my Pi this summer and
> got a corrupt file system  within hours.

Ah,

Thanks for the info.

I wonder if this is more to do with flash card reliability and the pi than fossil
and snapshots. I have been running fossil with snapshots for a year or so now and
not had a single crash.

I only use my Pi as a terminal so its flash is pretty much readonly.

-Steve

Re: [9fans] running plan9 : an ideal setup?

[dante]

Hi Steve,

how often do you snapshot? How large is the SD?
I used a 32G SD with  hourly snapshots, terminal server.

I would sort of rule out the SD reliability.
After reinstalling on the corrupt SD with snapshots off, no crashes for
months of always-on.

Thanks!
Dante

On 19.11.2014 11:18, Steve Simon wrote:
>> I never knew that there was a known bug there:
>> got my frist Plan9 this  summer.
>> I enabled snapshots on my Pi this summer and
>> got a corrupt file system  within hours.
>
> Ah,
>
> Thanks for the info.
>
> I wonder if this is more to do with flash card reliability and the pi
> than fossil
> and snapshots. I have been running fossil with snapshots for a year or
> so now and
> not had a single crash.
>
> I only use my Pi as a terminal so its flash is pretty much readonly.
>
> -Steve

Re: [9fans] running plan9 : an ideal setup?

[Quintile]

I have 500gb hard disks, mirrored, for fossil and venti. I take ephemeral snapshots every 15 mins, kept for 7 days, and nightly archival snapshots kept forever. this has been running for just over 10 years. though not continuously😄

I have the same setup at wok and at home

Steve





> On 19 Nov 2014, at 10:27, dante <subscriptions@posteo.eu> wrote:
> 
> Hi Steve,
> 
> how often do you snapshot? How large is the SD?
> I used a 32G SD with  hourly snapshots, terminal server.
> 
> I would sort of rule out the SD reliability.
> After reinstalling on the corrupt SD with snapshots off, no crashes for months of always-on.
> 
> Thanks!
> Dante
> 
> On 19.11.2014 11:18, Steve Simon wrote:
>>> I never knew that there was a known bug there:
>>> got my frist Plan9 this  summer.
>>> I enabled snapshots on my Pi this summer and
>>> got a corrupt file system  within hours.
>> Ah,
>> Thanks for the info.
>> I wonder if this is more to do with flash card reliability and the pi
>> than fossil
>> and snapshots. I have been running fossil with snapshots for a year or
>> so now and
>> not had a single crash.
>> I only use my Pi as a terminal so its flash is pretty much readonly.
>> -Steve

Re: [9fans] running plan9 : an ideal setup?

[lucio]

> I have been running fossil with snapshots for a year or so now and
> not had a single crash.

Is there an easy way to determine when a Fossil/Venti service was
first deployed?  I have a feeling my specific installation is a good
few years old and I'm pretty sure any problem that may have arisen
could not have been hard to fix.

Just as a guideline:

ripple# hget 'http://127.1:8000/storage'
index=main
total arenas=25 active=14
total space=13,224,894,464 used=7,374,207,851
clumps=2,660,366 compressed clumps=2,197,678 data=15,481,985,505 compressed data=7,206,604,793


I don't keep media stuff, so a lot of this reflects changes over time
rather than quantity of data.  I do have many versions of Go
development in place.

Lucio.

PS: It would seem I rebuilt the system (hoping to add disk capacity)
little over a year ago:

	d-r-xr-xr-x S 0 proxima proxima 0 Jul 22  2013 /dev/sd00

This is a VMware ESX server permanently on.

Re: [9fans] running plan9 : an ideal setup?

[Anthony Sorace]

> On Nov 19, 2014, at 5:36 , lucio@proxima.alt.za wrote:
> 
> Is there an easy way to determine when a Fossil/Venti service was
> first deployed?  I have a feeling my specific installation is a good
> few years old and I'm pretty sure any problem that may have arisen
> could not have been hard to fix.
> 
> Just as a guideline:
> 
> ripple# hget 'http://127.1:8000/storage'

Ask for /index instead of /storage. Each arena line will give you a "created=xxx" tag, where "xxx" is a timestamp. You could do an awk script to give you growth over time, if you like.

Re: [9fans] running plan9 : an ideal setup?

[lucio]

> Ask for /index instead of /storage.  Each arena line will give you a
> "created=xxx" tag, where "xxx" is a timestamp.  You could do an awk
> script to give you growth over time, if you like.

I looked for that, but I must have managed to overlook these fields.

Here is the first:

	Sat Jul 31 14:14:12 SAT 2010

Of course, the question was about Fossil's reliability and I'm sure
some will expect a level that is much better attained by backing
Fossil with Venti, no matter how robust Fossil may be.

Lucio.


-------------------------------------------------------------------------------------
This email has been scanned by the MxScan Email Security System.
-------------------------------------------------------------------------------------