Hi,
On Fri, Aug 7, 2009 at 2:52 AM, Richard A. Smithrich...@laptop.org wrote:
Benjamin M. Schwartz wrote:
Martin Langhoff wrote:
I would urge...
...you are preaching to the ultra-converted, to the frustrated. I
wasn't personally involved, but I know at least Wad Mitch looked
quite deep
On Wed, Aug 5, 2009 at 11:52 PM, Albert Cahalanacaha...@gmail.com wrote:
Gentlemen, before LVM can be considered, we need
- fs resize that is fail-safe in the face of powerloss, for the fs
types we plan to use.
- lvm resize that is fail-safe in the face of powerloss
Unless you have a bug
Martin Langhoff wrote:
On Wed, Aug 5, 2009 at 11:52 PM, Albert Cahalanacaha...@gmail.com wrote:
BTW, note that the flash disk itself is not certain to be
fail-safe in the face of powerloss. Neither the firmware
Sure. In practice it seems to be extremely safe, as wedged NAND is one
thing we
On Thu, Aug 6, 2009 at 8:30 AM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
The XO-1.5 will not be using raw NAND, nor will it be running jffs2.
ext3 is quite unclean-shutdown tolerant in my experience -
There will be a microcontroller (running uneditable proprietary firmware)
Martin Langhoff wrote:
I would urge...
...you are preaching to the ultra-converted, to the frustrated. I
wasn't personally involved, but I know at least Wad Mitch looked
quite deep into this, and found no good offers. There is good evidence
to trust them in hardware and low level firmware
Benjamin M. Schwartz wrote:
Martin Langhoff wrote:
I would urge...
...you are preaching to the ultra-converted, to the frustrated. I
wasn't personally involved, but I know at least Wad Mitch looked
quite deep into this, and found no good offers. There is good evidence
to trust them in
Richard A. Smith wrote:
In the end we chose to use microSDHC cards.
For MP, will they be soldered down or on contacts?
I like this; I think it creates the potential for all sorts of interesting
hackery and upgrades.
--Ben
signature.asc
Description: OpenPGP digital signature
Benjamin M. Schwartz wrote:
Richard A. Smith wrote:
In the end we chose to use microSDHC cards.
For MP, will they be soldered down or on contacts?
PCB mount cell phone style connector. You can change the card but you
have to take the plastic back and heatspreader off first.
I like this;
On Aug 6, 2009, at 10:12 PM, Richard A. Smith wrote:
Benjamin M. Schwartz wrote:
Richard A. Smith wrote:
In the end we chose to use microSDHC cards.
For MP, will they be soldered down or on contacts?
PCB mount cell phone style connector. You can change the card but you
have to take the
On Thu, Aug 06, 2009 at 09:52:59PM -0400, Richard A. Smith wrote:
In the end we chose to use microSDHC cards. The B1/B2 build will have
3 different mfg's of cards for qualification tests. Random power
failures are part of the qualification tests.
Great news, both of it, thanks! It means old
On Tue, Aug 4, 2009 at 2:32 PM, Martin
Langhoffmartin.langh...@gmail.com wrote:
On Tue, Aug 4, 2009 at 4:42 AM, Albert Cahalanacaha...@gmail.com wrote:
First partition: FAT16 with 4 KB clusters
Second partition: LVM with ext4
Gentlemen, before LVM can be considered, we need
- fs resize
LVM has a level of appeal. But it caused me a lot of trouble once.
I'd built a striped ext2 filesystem using it, so I could get enough
disk bandwidth to record raw sampled HDTV radio signals in realtime,
using Mandrake Linux and GNU Radio. When I upgraded that system to
Fedora a few years later,
First partition: FAT16 with 4 KB clusters
Second partition: LVM with ext4
In the LVM, filesystems should be 50% to 80% full. This leaves some
extra space unused. As filesystems fill up, the filesystems can be
expanded to use the extra space.
Don't shrink filesystems unless they drop down to 15%
On Tue, Aug 4, 2009 at 4:42 AM, Albert Cahalanacaha...@gmail.com wrote:
First partition: FAT16 with 4 KB clusters
Second partition: LVM with ext4
Gentlemen, before LVM can be considered, we need
- fs resize that is fail-safe in the face of powerloss, for the fs
types we plan to use.
- lvm
Once BTRFS is mature, yum learns to snapshot-upgrade-or-revert and we
switch to that combo, we will be able to retire olpc-update, the
symlink trees and the fancy overlays.
Do you have a prediction (I mean an educated guess) about when will
BTRFS be mature? What I heard last time that
Hi,
Do you have a prediction (I mean an educated guess) about when
will BTRFS be mature?
The developers recently said in at least a year from now.
For some particular features that we would need before adopting it:
2.6.31: hopefully ENOSPC bug will be fixed
2.6.32: ability to delete
sascha wrote:
good stuff about LVM
thank you. i was aware of LVM, but didn't realize it would accomplish
quite what i was proposing.
Having used LVM, I am less that enthusiastic about it. It definitely
requires a lot of cooperation from the filesystem, the process is
cumbersome, and
On Sun, Aug 02, 2009 at 05:34:26PM -0600, Martin Langhoff wrote:
Having used LVM, I am less that enthusiastic about it. It definitely
requires a lot of cooperation from the filesystem, the process is
cumbersome, and data-loss prone.
Care to elaborate? I've been using LVM for many years on lots
On Mon, Aug 3, 2009 at 3:20 AM, Sascha
Silbesascha-ml-ui-sugar-olpc-de...@silbe.org wrote:
Care to elaborate? I've been using LVM for many years on lots of systems and
never had a single problem.
How does it require cooperation from the filesystem? It's just a block
layer, you can store
On Tue, Jul 28, 2009 at 2:34 PM, Paul Foxp...@laptop.org wrote:
sascha wrote:
good stuff about LVM
thank you. i was aware of LVM, but didn't realize it would accomplish
quite what i was proposing.
Having used LVM, I am less that enthusiastic about it. It definitely
requires a lot of
On Jul 27 2009, at 12:17, Mitch Bradley was caught saying:
/ - 2 GB - ext4
Contains system files
How about having 2x1GiB system partitions so that instead of doing
the symlink stuff we do right now, we can just mount the appropriate
system parition as the root partition? Metadata for
On Jul 27 2009, at 13:27, Mitch Bradley was caught saying:
The filesystem is no longer internally compressed. The current size for
the XO-1.5 system is 1.1 GB. 2 GB gives some headroom for growth and
for temporary overages during updates.
Chris,
Are we stuck with 1.1GiB or do we think we
Hi,
How about having 2x1GiB system partitions so that instead of
doing the symlink stuff we do right now, we can just mount the
appropriate system parition as the root partition? Metadata for
which partition contains the most recent OS image could be stored
in /boot.
Well,
Hi, [adding fedora-olpc-list to CC]
Are we stuck with 1.1GiB or do we think we can reduce that further?
Well, there are a few things going on here. We have activities and
content (and will probably add more activities and content) that's
currently part of the 1.1GiB, but is actually in
On Tue, 28 Jul 2009, Chris Ball wrote:
Hi, [adding fedora-olpc-list to CC]
Are we stuck with 1.1GiB or do we think we can reduce that further?
Well, there are a few things going on here. We have activities and
content (and will probably add more activities and content) that's
currently
Another important advantage to partitions is that the existence of a
boot partition isolates the firmware from changes in the filesystem used
for the root.
Advantage #2 that you cite below is also quite valuable - it makes it
easy to preserve user data while replacing/recovering/updating the
On Tue, 28 Jul 2009, Mitch Bradley wrote:
Another important advantage to partitions is that the existence of a boot
partition isolates the firmware from changes in the filesystem used for the
root.
can you explain this a bit more?
Advantage #2 that you cite below is also quite valuable -
da...@lang.hm wrote:
disadvantages to using partitions
primarily boils down to one
you have to decide ahead of time how big to make the partitions, and
changing this later is non-trivial. if you guess wrong you can end up
running out of space in one place while you have extra
Hi,
Another important advantage to partitions is that the existence
of a boot partition isolates the firmware from changes in the
filesystem used for the root.
can you explain this a bit more?
Concrete example: if you want to use btrfs on your root filesystem,
you must have
da...@lang.hm wrote:
On Tue, 28 Jul 2009, Mitch Bradley wrote:
Another important advantage to partitions is that the existence of a
boot partition isolates the firmware from changes in the filesystem
used for the root.
can you explain this a bit more?
A conventional BIOS boots by
On Tue, 28 Jul 2009, Paul Fox wrote:
da...@lang.hm wrote:
disadvantages to using partitions
primarily boils down to one
you have to decide ahead of time how big to make the partitions, and
changing this later is non-trivial. if you guess wrong you can end up
running out of space in
sascha wrote:
good stuff about LVM
thank you. i was aware of LVM, but didn't realize it would accomplish
quite what i was proposing.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
On Tue, 28 Jul 2009, Mitch Bradley wrote:
da...@lang.hm wrote:
On Tue, 28 Jul 2009, Mitch Bradley wrote:
Another important advantage to partitions is that the existence of a boot
partition isolates the firmware from changes in the filesystem used for
the root.
can you explain this a
lilo is nearly worst of breed in terms of putting magic stuff in the
Master Boot Record.
da...@lang.hm wrote:
On Tue, 28 Jul 2009, Mitch Bradley wrote:
da...@lang.hm wrote:
On Tue, 28 Jul 2009, Mitch Bradley wrote:
Another important advantage to partitions is that the existence of
a boot
On Tue, 28 Jul 2009, Mitch Bradley wrote:
lilo is nearly worst of breed in terms of putting magic stuff in the Master
Boot Record.
every boot loader puts stuff in the master boot record (it's own code if
nothing else)
lilo puts everything there needed to find the disk blocks it needs.
This is a request for comments on a proposed disk layout for XO-1.5.
XO-1.5 will have managed NAND instead of raw NAND, so we can use
conventional filesystems instead of e.g. JFFS2.
Proposal:
The internal NAND storage will be partitioned with an FDISK partition
map, into three partitions
Why such a large system partition?
-walter
On Mon, Jul 27, 2009 at 6:17 PM, Mitch Bradleyw...@laptop.org wrote:
This is a request for comments on a proposed disk layout for XO-1.5.
XO-1.5 will have managed NAND instead of raw NAND, so we can use
conventional filesystems instead of e.g. JFFS2
Bradleyw...@laptop.org wrote:
This is a request for comments on a proposed disk layout for XO-1.5.
XO-1.5 will have managed NAND instead of raw NAND, so we can use
conventional filesystems instead of e.g. JFFS2.
Proposal:
The internal NAND storage will be partitioned with an FDISK partition
mitch wrote:
This is a request for comments on a proposed disk layout for XO-1.5.
XO-1.5 will have managed NAND instead of raw NAND, so we can use
conventional filesystems instead of e.g. JFFS2.
Proposal:
The internal NAND storage will be partitioned with an FDISK partition
I agree with the proposal.
I'm on the other side with respect to size of root ... 2 GB doesn't seem
safe enough given the current 1.1 GB size we have. But on the other
hand, repartitioning later is probably quite practical.
--
James Cameron
http://quozl.linux.org.au/
Mitch Bradley wrote:
The filesystem is no longer internally compressed. The current size for
the XO-1.5 system is 1.1 GB.
Interesting.
Build 767 had an ext3 version:
http://download.laptop.org/xo-1/os/official/767/ext3/xo-1-olpc-stream-8.2-build-767-20081001_1633-devel_ext3-tree.tar.bz2
41 matches
Mail list logo
