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
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
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
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
On Fri Nov 28 01:15:32 PST 2014, 9f...@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
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
On Thu Nov 27 12:55:40 PST 2014, subscripti...@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
fossil has no option to disable atime, but kfs does.
The Fossil open command takes the option -a to
disable atime.
--
David du Colombier
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
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
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 subscripti...@posteo.eu:
Hi Mats,
Look in the /dev directory (ls /dev).
If you only have the boot device and an additional USB drive (in
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@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,
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@gmail.com:
Hi!
So piclone sdU0.0 would be right? I have the script in
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
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)
On Nov 25, 2014, at 1:59 , Bakul Shah ba...@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
On Tue Nov 25 08:52:33 EST 2014, a...@9srv.net wrote:
On Nov 25, 2014, at 1:59 , Bakul Shah ba...@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.
On Sat, 22 Nov 2014 13:06:15 EST erik quanstrom quans...@quanstro.net wrote:
On Fri Nov 21 12:31:13 EST 2014, ba...@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
On Fri Nov 21 12:31:13 EST 2014, ba...@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
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
On Nov 21, 2014, at 9:34 , erik quanstrom quans...@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
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
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.
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
On 19 Nov 2014 23:54, Tom Ivar Helbekkmo t...@hamartun.priv.no wrote:
Richard Miller 9f...@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
Hi dante!
Thanks a lot! Now I have saved the script.
Kind regards,
Mats
2014-11-18 23:09 GMT+01:00, dante subscripti...@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.
- 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
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
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
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,
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
On Wed Nov 19 00:36:36 EST 2014, skip.tavakkol...@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
On Wed Nov 19 01:07:43 EST 2014, lu...@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
On Wed, Nov 19, 2014 at 3:36 PM, erik quanstrom quans...@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
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
On Tue, 18 Nov 2014 20:29:30 GMT Richard Miller 9f...@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
Richard Miller 9f...@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
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
On Nov 19, 2014, at 5:36 , lu...@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.
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
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
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.
Quoting dante subscripti...@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
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 subscripti...@posteo.eu:
- 9Front: comes with the experimental hjfs by
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
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
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 9f...@hamnavoe.com:
If you must use a rpi, you should strive to use it as a
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
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
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
On Tue Nov 18 17:10:59 EST 2014, skip.tavakkol...@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
On Tue Nov 18 12:03:04 EST 2014, ara...@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
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
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 quans...@quanstro.net
wrote:
On Tue Nov 18 17:10:59 EST 2014,
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
55 matches
Mail list logo
