* [9fans] running plan9 : an ideal setup? @ 2014-11-18 13:29 Mayuresh Kathe 2014-11-18 13:53 ` dante 0 siblings, 1 reply; 59+ messages in thread From: Mayuresh Kathe @ 2014-11-18 13:29 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 13:29 [9fans] running plan9 : an ideal setup? Mayuresh Kathe @ 2014-11-18 13:53 ` dante 2014-11-18 14:11 ` Richard Miller ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: dante @ 2014-11-18 13:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 13:53 ` dante @ 2014-11-18 14:11 ` Richard Miller 2014-11-18 14:28 ` dante 2014-11-27 20:57 ` Dante 2014-11-18 15:42 ` Kurt H Maier 2014-11-19 9:40 ` Steve Simon 2 siblings, 2 replies; 59+ messages in thread From: Richard Miller @ 2014-11-18 14:11 UTC (permalink / raw) To: 9fans > - 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 14:11 ` Richard Miller @ 2014-11-18 14:28 ` dante 2014-11-27 20:57 ` Dante 1 sibling, 0 replies; 59+ messages in thread From: dante @ 2014-11-18 14:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Richard Miller 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 14:11 ` Richard Miller 2014-11-18 14:28 ` dante @ 2014-11-27 20:57 ` Dante 2014-11-28 6:10 ` erik quanstrom 1 sibling, 1 reply; 59+ messages in thread From: Dante @ 2014-11-27 20:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-27 20:57 ` Dante @ 2014-11-28 6:10 ` erik quanstrom 2014-11-28 6:54 ` David du Colombier 0 siblings, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-28 6:10 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 6:10 ` erik quanstrom @ 2014-11-28 6:54 ` David du Colombier 2014-11-28 8:42 ` Dante 2014-11-28 9:17 ` Richard Miller 0 siblings, 2 replies; 59+ messages in thread From: David du Colombier @ 2014-11-28 6:54 UTC (permalink / raw) To: 9fans > fossil has no option to disable atime, but kfs does. The Fossil "open" command takes the option "-a" to disable atime. -- David du Colombier ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 6:54 ` David du Colombier @ 2014-11-28 8:42 ` Dante 2014-11-28 9:12 ` Mats Olsson 2014-11-28 9:17 ` Richard Miller 1 sibling, 1 reply; 59+ messages in thread From: Dante @ 2014-11-28 8:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 8:42 ` Dante @ 2014-11-28 9:12 ` Mats Olsson 2014-11-28 9:18 ` Dante 0 siblings, 1 reply; 59+ messages in thread From: Mats Olsson @ 2014-11-28 9:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 9:12 ` Mats Olsson @ 2014-11-28 9:18 ` Dante 0 siblings, 0 replies; 59+ messages in thread From: Dante @ 2014-11-28 9:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 >> >> ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 6:54 ` David du Colombier 2014-11-28 8:42 ` Dante @ 2014-11-28 9:17 ` Richard Miller 2014-11-28 9:26 ` Dante 2014-11-28 13:20 ` erik quanstrom 1 sibling, 2 replies; 59+ messages in thread From: Richard Miller @ 2014-11-28 9:17 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 9:17 ` Richard Miller @ 2014-11-28 9:26 ` Dante 2014-11-28 13:20 ` erik quanstrom 1 sibling, 0 replies; 59+ messages in thread From: Dante @ 2014-11-28 9:26 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 9:17 ` Richard Miller 2014-11-28 9:26 ` Dante @ 2014-11-28 13:20 ` erik quanstrom 2014-11-28 13:45 ` David du Colombier 1 sibling, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-28 13:20 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-28 13:20 ` erik quanstrom @ 2014-11-28 13:45 ` David du Colombier 0 siblings, 0 replies; 59+ messages in thread From: David du Colombier @ 2014-11-28 13:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 13:53 ` dante 2014-11-18 14:11 ` Richard Miller @ 2014-11-18 15:42 ` Kurt H Maier 2014-11-18 16:14 ` dante 2014-11-19 9:40 ` Steve Simon 2 siblings, 1 reply; 59+ messages in thread From: Kurt H Maier @ 2014-11-18 15:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 15:42 ` Kurt H Maier @ 2014-11-18 16:14 ` dante 2014-11-18 17:02 ` Aram Hăvărneanu 0 siblings, 1 reply; 59+ messages in thread From: dante @ 2014-11-18 16:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 16:14 ` dante @ 2014-11-18 17:02 ` Aram Hăvărneanu 2014-11-18 20:29 ` Richard Miller 2014-11-19 2:04 ` erik quanstrom 0 siblings, 2 replies; 59+ messages in thread From: Aram Hăvărneanu @ 2014-11-18 17:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 17:02 ` Aram Hăvărneanu @ 2014-11-18 20:29 ` Richard Miller 2014-11-18 21:28 ` Mats Olsson ` (3 more replies) 2014-11-19 2:04 ` erik quanstrom 1 sibling, 4 replies; 59+ messages in thread From: Richard Miller @ 2014-11-18 20:29 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 20:29 ` Richard Miller @ 2014-11-18 21:28 ` Mats Olsson 2014-11-18 22:09 ` dante 2014-11-18 22:11 ` Skip Tavakkolian ` (2 subsequent siblings) 3 siblings, 1 reply; 59+ messages in thread From: Mats Olsson @ 2014-11-18 21:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > > > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 21:28 ` Mats Olsson @ 2014-11-18 22:09 ` dante 2014-11-19 8:56 ` Mats Olsson 2014-11-26 17:16 ` Mats Olsson 0 siblings, 2 replies; 59+ messages in thread From: dante @ 2014-11-18 22:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 22:09 ` dante @ 2014-11-19 8:56 ` Mats Olsson 2014-11-26 17:16 ` Mats Olsson 1 sibling, 0 replies; 59+ messages in thread From: Mats Olsson @ 2014-11-19 8:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>> >>> >>> ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 22:09 ` dante 2014-11-19 8:56 ` Mats Olsson @ 2014-11-26 17:16 ` Mats Olsson 2014-11-26 17:41 ` Dante 1 sibling, 1 reply; 59+ messages in thread From: Mats Olsson @ 2014-11-26 17:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>> >>> >>> ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-26 17:16 ` Mats Olsson @ 2014-11-26 17:41 ` Dante 2014-11-26 17:56 ` Mats Olsson 0 siblings, 1 reply; 59+ messages in thread From: Dante @ 2014-11-26 17:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>>> >>>> >>>> ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-26 17:41 ` Dante @ 2014-11-26 17:56 ` Mats Olsson 2014-11-26 18:16 ` Mats Olsson 0 siblings, 1 reply; 59+ messages in thread From: Mats Olsson @ 2014-11-26 17:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>>>> >>>>> >>>>> > > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-26 17:56 ` Mats Olsson @ 2014-11-26 18:16 ` Mats Olsson 2014-11-26 18:41 ` Dante 0 siblings, 1 reply; 59+ messages in thread From: Mats Olsson @ 2014-11-26 18:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>>>>> >>>>>> >>>>>> >> >> > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-26 18:16 ` Mats Olsson @ 2014-11-26 18:41 ` Dante 0 siblings, 0 replies; 59+ messages in thread From: Dante @ 2014-11-26 18:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. >>>>>>> >>>>>>> >>>>>>> >>> >>> >> ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 20:29 ` Richard Miller 2014-11-18 21:28 ` Mats Olsson @ 2014-11-18 22:11 ` Skip Tavakkolian 2014-11-18 22:23 ` Steve Simon 2014-11-19 1:57 ` erik quanstrom 2014-11-19 20:05 ` Bakul Shah 2014-11-19 20:40 ` Tom Ivar Helbekkmo 3 siblings, 2 replies; 59+ messages in thread From: Skip Tavakkolian @ 2014-11-18 22:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 22:11 ` Skip Tavakkolian @ 2014-11-18 22:23 ` Steve Simon 2014-11-19 1:57 ` erik quanstrom 1 sibling, 0 replies; 59+ messages in thread From: Steve Simon @ 2014-11-18 22:23 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 22:11 ` Skip Tavakkolian 2014-11-18 22:23 ` Steve Simon @ 2014-11-19 1:57 ` erik quanstrom 2014-11-19 5:36 ` Skip Tavakkolian 1 sibling, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-19 1:57 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 1:57 ` erik quanstrom @ 2014-11-19 5:36 ` Skip Tavakkolian 2014-11-19 5:59 ` lucio 2014-11-19 14:33 ` erik quanstrom 0 siblings, 2 replies; 59+ messages in thread From: Skip Tavakkolian @ 2014-11-19 5:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- 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 --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 5:36 ` Skip Tavakkolian @ 2014-11-19 5:59 ` lucio 2014-11-19 14:36 ` erik quanstrom 2014-11-19 14:33 ` erik quanstrom 1 sibling, 1 reply; 59+ messages in thread From: lucio @ 2014-11-19 5:59 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 5:59 ` lucio @ 2014-11-19 14:36 ` erik quanstrom 2014-11-19 15:34 ` Aram Hăvărneanu 0 siblings, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-19 14:36 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 14:36 ` erik quanstrom @ 2014-11-19 15:34 ` Aram Hăvărneanu 2014-11-20 6:02 ` Anthony Sorace 0 siblings, 1 reply; 59+ messages in thread From: Aram Hăvărneanu @ 2014-11-19 15:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 15:34 ` Aram Hăvărneanu @ 2014-11-20 6:02 ` Anthony Sorace 2014-11-20 14:37 ` erik quanstrom 0 siblings, 1 reply; 59+ messages in thread From: Anthony Sorace @ 2014-11-20 6:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-20 6:02 ` Anthony Sorace @ 2014-11-20 14:37 ` erik quanstrom 2014-11-20 18:43 ` Anthony Sorace 0 siblings, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-20 14:37 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-20 14:37 ` erik quanstrom @ 2014-11-20 18:43 ` Anthony Sorace 2014-11-21 14:34 ` erik quanstrom 0 siblings, 1 reply; 59+ messages in thread From: Anthony Sorace @ 2014-11-20 18:43 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-20 18:43 ` Anthony Sorace @ 2014-11-21 14:34 ` erik quanstrom 2014-11-21 14:44 ` Anthony Sorace 2014-11-21 17:31 ` Bakul Shah 0 siblings, 2 replies; 59+ messages in thread From: erik quanstrom @ 2014-11-21 14:34 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-21 14:34 ` erik quanstrom @ 2014-11-21 14:44 ` Anthony Sorace 2014-11-21 17:31 ` Bakul Shah 1 sibling, 0 replies; 59+ messages in thread From: Anthony Sorace @ 2014-11-21 14:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-21 14:34 ` erik quanstrom 2014-11-21 14:44 ` Anthony Sorace @ 2014-11-21 17:31 ` Bakul Shah 2014-11-22 18:06 ` erik quanstrom 1 sibling, 1 reply; 59+ messages in thread From: Bakul Shah @ 2014-11-21 17:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-21 17:31 ` Bakul Shah @ 2014-11-22 18:06 ` erik quanstrom 2014-11-25 6:59 ` Bakul Shah 0 siblings, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-22 18:06 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-22 18:06 ` erik quanstrom @ 2014-11-25 6:59 ` Bakul Shah 2014-11-25 11:10 ` erik quanstrom 2014-11-25 13:52 ` Anthony Sorace 0 siblings, 2 replies; 59+ messages in thread From: Bakul Shah @ 2014-11-25 6:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-25 6:59 ` Bakul Shah @ 2014-11-25 11:10 ` erik quanstrom 2014-11-25 11:14 ` erik quanstrom 2014-11-25 13:52 ` Anthony Sorace 1 sibling, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-25 11:10 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-25 11:10 ` erik quanstrom @ 2014-11-25 11:14 ` erik quanstrom 0 siblings, 0 replies; 59+ messages in thread From: erik quanstrom @ 2014-11-25 11:14 UTC (permalink / raw) To: 9fans > > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-25 6:59 ` Bakul Shah 2014-11-25 11:10 ` erik quanstrom @ 2014-11-25 13:52 ` Anthony Sorace 2014-11-25 14:26 ` erik quanstrom 1 sibling, 1 reply; 59+ messages in thread From: Anthony Sorace @ 2014-11-25 13:52 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-25 13:52 ` Anthony Sorace @ 2014-11-25 14:26 ` erik quanstrom 0 siblings, 0 replies; 59+ messages in thread From: erik quanstrom @ 2014-11-25 14:26 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 5:36 ` Skip Tavakkolian 2014-11-19 5:59 ` lucio @ 2014-11-19 14:33 ` erik quanstrom 1 sibling, 0 replies; 59+ messages in thread From: erik quanstrom @ 2014-11-19 14:33 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 20:29 ` Richard Miller 2014-11-18 21:28 ` Mats Olsson 2014-11-18 22:11 ` Skip Tavakkolian @ 2014-11-19 20:05 ` Bakul Shah 2014-11-19 20:40 ` Tom Ivar Helbekkmo 3 siblings, 0 replies; 59+ messages in thread From: Bakul Shah @ 2014-11-19 20:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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! ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 20:29 ` Richard Miller ` (2 preceding siblings ...) 2014-11-19 20:05 ` Bakul Shah @ 2014-11-19 20:40 ` Tom Ivar Helbekkmo 2014-11-21 6:34 ` Harri Haataja 3 siblings, 1 reply; 59+ messages in thread From: Tom Ivar Helbekkmo @ 2014-11-19 20:40 UTC (permalink / raw) To: Richard Miller; +Cc: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 20:40 ` Tom Ivar Helbekkmo @ 2014-11-21 6:34 ` Harri Haataja 0 siblings, 0 replies; 59+ messages in thread From: Harri Haataja @ 2014-11-21 6:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs; +Cc: Richard Miller [-- 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 --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 17:02 ` Aram Hăvărneanu 2014-11-18 20:29 ` Richard Miller @ 2014-11-19 2:04 ` erik quanstrom 2014-11-19 3:50 ` lucio 1 sibling, 1 reply; 59+ messages in thread From: erik quanstrom @ 2014-11-19 2:04 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 2:04 ` erik quanstrom @ 2014-11-19 3:50 ` lucio 0 siblings, 0 replies; 59+ messages in thread From: lucio @ 2014-11-19 3:50 UTC (permalink / raw) To: 9fans > 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. ------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-18 13:53 ` dante 2014-11-18 14:11 ` Richard Miller 2014-11-18 15:42 ` Kurt H Maier @ 2014-11-19 9:40 ` Steve Simon 2014-11-19 9:50 ` dante 2 siblings, 1 reply; 59+ messages in thread From: Steve Simon @ 2014-11-19 9:40 UTC (permalink / raw) To: 9fans > - 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 9:40 ` Steve Simon @ 2014-11-19 9:50 ` dante 2014-11-19 10:18 ` Steve Simon 0 siblings, 1 reply; 59+ messages in thread From: dante @ 2014-11-19 9:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 9:50 ` dante @ 2014-11-19 10:18 ` Steve Simon 2014-11-19 10:27 ` dante 2014-11-19 10:36 ` lucio 0 siblings, 2 replies; 59+ messages in thread From: Steve Simon @ 2014-11-19 10:18 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 10:18 ` Steve Simon @ 2014-11-19 10:27 ` dante 2014-11-19 18:55 ` Quintile 2014-11-19 10:36 ` lucio 1 sibling, 1 reply; 59+ messages in thread From: dante @ 2014-11-19 10:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 10:27 ` dante @ 2014-11-19 18:55 ` Quintile 0 siblings, 0 replies; 59+ messages in thread From: Quintile @ 2014-11-19 18:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 10:18 ` Steve Simon 2014-11-19 10:27 ` dante @ 2014-11-19 10:36 ` lucio 2014-11-20 6:05 ` Anthony Sorace 1 sibling, 1 reply; 59+ messages in thread From: lucio @ 2014-11-19 10:36 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-19 10:36 ` lucio @ 2014-11-20 6:05 ` Anthony Sorace 2014-11-20 6:13 ` lucio 0 siblings, 1 reply; 59+ messages in thread From: Anthony Sorace @ 2014-11-20 6:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > 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. ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [9fans] running plan9 : an ideal setup? 2014-11-20 6:05 ` Anthony Sorace @ 2014-11-20 6:13 ` lucio 0 siblings, 0 replies; 59+ messages in thread From: lucio @ 2014-11-20 6:13 UTC (permalink / raw) To: 9fans > 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. ------------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2014-11-28 13:45 UTC | newest] Thread overview: 59+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-11-18 13:29 [9fans] running plan9 : an ideal setup? Mayuresh Kathe 2014-11-18 13:53 ` dante 2014-11-18 14:11 ` Richard Miller 2014-11-18 14:28 ` dante 2014-11-27 20:57 ` Dante 2014-11-28 6:10 ` erik quanstrom 2014-11-28 6:54 ` David du Colombier 2014-11-28 8:42 ` Dante 2014-11-28 9:12 ` Mats Olsson 2014-11-28 9:18 ` Dante 2014-11-28 9:17 ` Richard Miller 2014-11-28 9:26 ` Dante 2014-11-28 13:20 ` erik quanstrom 2014-11-28 13:45 ` David du Colombier 2014-11-18 15:42 ` Kurt H Maier 2014-11-18 16:14 ` dante 2014-11-18 17:02 ` Aram Hăvărneanu 2014-11-18 20:29 ` Richard Miller 2014-11-18 21:28 ` Mats Olsson 2014-11-18 22:09 ` dante 2014-11-19 8:56 ` Mats Olsson 2014-11-26 17:16 ` Mats Olsson 2014-11-26 17:41 ` Dante 2014-11-26 17:56 ` Mats Olsson 2014-11-26 18:16 ` Mats Olsson 2014-11-26 18:41 ` Dante 2014-11-18 22:11 ` Skip Tavakkolian 2014-11-18 22:23 ` Steve Simon 2014-11-19 1:57 ` erik quanstrom 2014-11-19 5:36 ` Skip Tavakkolian 2014-11-19 5:59 ` lucio 2014-11-19 14:36 ` erik quanstrom 2014-11-19 15:34 ` Aram Hăvărneanu 2014-11-20 6:02 ` Anthony Sorace 2014-11-20 14:37 ` erik quanstrom 2014-11-20 18:43 ` Anthony Sorace 2014-11-21 14:34 ` erik quanstrom 2014-11-21 14:44 ` Anthony Sorace 2014-11-21 17:31 ` Bakul Shah 2014-11-22 18:06 ` erik quanstrom 2014-11-25 6:59 ` Bakul Shah 2014-11-25 11:10 ` erik quanstrom 2014-11-25 11:14 ` erik quanstrom 2014-11-25 13:52 ` Anthony Sorace 2014-11-25 14:26 ` erik quanstrom 2014-11-19 14:33 ` erik quanstrom 2014-11-19 20:05 ` Bakul Shah 2014-11-19 20:40 ` Tom Ivar Helbekkmo 2014-11-21 6:34 ` Harri Haataja 2014-11-19 2:04 ` erik quanstrom 2014-11-19 3:50 ` lucio 2014-11-19 9:40 ` Steve Simon 2014-11-19 9:50 ` dante 2014-11-19 10:18 ` Steve Simon 2014-11-19 10:27 ` dante 2014-11-19 18:55 ` Quintile 2014-11-19 10:36 ` lucio 2014-11-20 6:05 ` Anthony Sorace 2014-11-20 6:13 ` lucio
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).