From: | dalgoda(at)ix(dot)netcom(dot)com (Mike Castle) |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres on a PDA |
Date: | 2003-01-15 17:20:53 |
Message-ID: | lshgfxlof.ln2@thune.mrc-home.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
In article <1883(dot)1042606899(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>attention I think it was on the order of magnitude of 10000 write
>cycles --- which Postgres could blow through in no time. I hope
>it's better now, but I dunno by how much. Anyone have more
>up-to-date info?
Only about 1 order of magnitude better. From the Linux Embedded FAQ:
3.3 Flash Limited write cycles
Flash have limited write cycles capabilities from 200 000 to 400 000.
Using swap on such device is dangerous. 300 000 writes gives you 200
days at 1 write / minute and 83 hours at 1 write / second. More, If
you interrupt power at arbitrary times while the device is writing,
you can lose the integrity of the file system being modified. The loss
is not limited to the 512 byte sector being modified, as it generally
is with rotating disks; you can lose an entire erase block, maybe 64K
at once. The risk goes up as the "disk" approaches full, because erase
rewrite cycles happen more often in this condition. Un*x file systems
spread their super block tables around the "disk", in the hope that at
least one will survive a head crash. Create one file, then /bin/sync:
what percentage of the device's erase blocks get hit?
I like the part that goes "you can lose the integrity of the file system
being modified."
To be honest, would BerkeleyDB be better?
mrc
--
Mike Castle dalgoda(at)ix(dot)netcom(dot)com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Hallstrom | 2003-01-15 17:32:47 | Re: postgres on a PDA |
Previous Message | dev | 2003-01-15 17:17:23 | Re: Wrong query execution. |