Mon, 23 Jun 2008

On Jun 23, 2008, at 1:50 PM, Aristotle Pagaltzis wrote:

> The problem with the Reiser family FSs is that they are
> inherently brittle. Now that they have been sufficiently
> debugged, they no longer lose data often, but if you have
> even a small unrepairable corruption, it is still more likely
> that you’ll lose half your disk instead of just a few files, as
> is the extX family’s failure mode.

How do you know this?  It doesn't seem to be implied by any of the  
papers that I referenced, but nor is it contradicted by them.  I  
would like more data.

Regards,

Zooko

* zooko <zooko at zooko.com> [2008-06-23 20:35]:
> I'm not sure what the use case we're talking about is,
> but for many use cases reiser3 is a good choice.

The problem with the Reiser family FSs is that they are
inherently brittle. Now that they have been sufficiently
debugged, they no longer lose data often, but if you have
even a small unrepairable corruption, it is still more likely
that you’ll lose half your disk instead of just a few files, as
is the extX family’s failure mode.

So even now I would not entrust either Reiser-family FS with data
that I care about. Hence my suggestion of putting the less huge-
tree-performance sensitive git store on another partition and
keeping only the working copy on reiserX.

The other thing about the Reiser-family FSs is that they eat
enormous amounts of CPU, to the point that they can *fully peg*
a CPU during I/O.

> Andrew Morton vaguely recalled something like 30% performance
> loss when turning on write barriers for ext3.

Yes, ext3 is slow. It is much faster than the Btree-based FSs in
a select few circumstances, but in general, it is slow or very
slow.

> Chris Mason (who worked on reiser3 at the time and is I think
> chief architect of btrfs now) cooked up a test script which
> could cause filesystem corruption in ext3 with about 50%
> probability in case of power loss.

Right, but how much data gets lost in such a case? In my
experience and that of every sysadmin I’ve asked, unrecoverable
corruption is essentially always quite localised with extX.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Jun 23, 2008, at 7:15 AM, Aristotle Pagaltzis wrote:

> I guess it’s down to JFS…

I'm not sure what the use case we're talking about is, but for many  
use cases reiser3 is a good choice.  Here are a few links to papers  
which analyzed various filesystems (including reiser3, JFS, XFS,  
ext3, and NTFS) and which altogether suggest that reiser3 is better  
engineered for data correctness (at the expense of availability) than  
most:

http://allmydata.org/trac/tahoe/wiki/Bibliography#LocalFilesystems

Also note that I recently learned that the benchmarks that we've  
looked at over the years were mostly done with write barriers turned  
on by reiser3 and write barriers turned off by ext3:

http://lwn.net/Articles/283161

Andrew Morton vaguely recalled something like 30% performance loss  
when turning on write barriers for ext3.

The thread is interesting to follow.  Chris Mason (who worked on  
reiser3 at the time and is I think chief architect of btrfs now)  
cooked up a test script which could cause filesystem corruption in  
ext3 with about 50% probability in case of power loss.

I agree that ZFS and btrfs are interesting alternatives, and I also  
remain interested in reiser4.  Note that you can use ZFS today on a  
Free Software operating system -- just install OpenSolaris.  (I use  
Nexenta -- Solaris with apt-get.)

Regards,

Zooko

On Mon, Jun 23, 2008 at 04:15:48PM +0200, Aristotle Pagaltzis wrote:

> Wow. What use is journaling when a system crash leaves your
> filesystem corrupted anyway?

Yes, it is rather unfortunate. But if your system doesn't panic/lock up
and has an UPS xfs works well.
 
> I guess it’s down to JFS… except that JFS reportedly performs
> poorly with voluminous trees (although still better than ext3,
> as far as I understood).
> 
> So maybe in the end the conclusion is to use reiser4 for the
> working directory and keep a regularly-repacked git store on
> a more robust filesystem. (You can set the `GIT_DIR` environment
> variable to tell git commands where to look for it.)
> 
> That doesn’t address the issue that though fast, both reiserfs
> and reiser4 are very CPU-hungry, though.
> 
> Pity that btrfs is basically just an alpha even now…

I'm hoping for a GPL-compatible zfs license in a year or two.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

* Eugen Leitl <eugen at leitl.org> [2008-06-23 11:50]:
> When using XFS make sure your system is backed up by an UPS,
> and doesn't crash. I wouldn't use it as a root filesystem
> otherwise.

Wow. What use is journaling when a system crash leaves your
filesystem corrupted anyway?

I guess it’s down to JFS… except that JFS reportedly performs
poorly with voluminous trees (although still better than ext3,
as far as I understood).

So maybe in the end the conclusion is to use reiser4 for the
working directory and keep a regularly-repacked git store on
a more robust filesystem. (You can set the `GIT_DIR` environment
variable to tell git commands where to look for it.)

That doesn’t address the issue that though fast, both reiserfs
and reiser4 are very CPU-hungry, though.

Pity that btrfs is basically just an alpha even now…

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

On Sat, Jun 21, 2008 at 10:58:52AM +0200, Aristotle Pagaltzis wrote:

> Both suggest that you may want to consider XFS or JFS instead.

When using XFS make sure your system is backed up by an UPS, and
doesn't crash. I wouldn't use it as a root filesystem otherwise.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

(Available in HTML at <http://canonical.org/~kragen/wood-pda.html>.)

Polished-Stone Handheld Computers
---------------------------------

So I've been thinking about making a handheld computer with the look
and feel (shininess, irregularity, weight, seamlessness) of a polished
semiprecious stone.

One way to do this would be to embed the electronics in polyester
resin poured into a mold, with an embedded induction coil for
charging, some embedded lead shot for weight, and a dark, but not
quite opaque, surface layer to hide the interior except for when it
was glowing.  Input would probably be piezoelectric, localizing
surface taps or using rhythm.  (See earlier kragen-tol post [magic
boxes and secret knocks][magic].)  Output could be through embedded
LEDs shining through the surface layer or through audio, especially if
you held it against a window.

(How much lead shot would you need?  Lead has a density of 11.3g/cc,
against quartz's 2.6g/cc and [the polyester resin's 1.11g/cc][EP4117],
so only 14.6% of the volume would need to be lead to equal quartz's
density.)

It would be shockproof, waterproof, crushproof, not particularly prone
to damage from ESD, and it would feel really good in your hand.  Some
hard silicone around the outside might improve its thermal
conductivity.  (There are hard silicone resins with high thermal
conductivity, right?)

Beatrice suggested that you could use an actual polished semiprecious
stone instead; cut out a circle from one side, drill out a cavity
underneath, put the electronics inside, pot them with epoxy, replace
the circle, wipe off the excess epoxy, and then polish the result.

Wood-Block Handheld Computers
-----------------------------

Another "everyday object" kind of electronic device case: a block of
wood.  Some time ago I saw a web page about a wooden clock.  It seems
to be widely available now; for example,
<http://svp.co.uk/products-solo.php?pid=4989&ref=froogle&ci_src=18615224&ci_sku=8028>
advertises it for £93.99.  It explains:

> A totally minimal block of wood with digital numbers floating
> across the surface. These clever clocks have a very thin layer of
> real maple wood veneer that permits the LEDs to shine through.
> 
> Each one is slightly different due to the natural variation in
> wood grain.
> 
> Dimensions: 208 x 90 x 90mm
> Weight: 1.2kg

Another page says:

> TO:CA 'wood' LED clock designed by kouji iwasaki in 2002. this
> 'wooden' LED clock won top prize at the asahikawa international
> design fair in 2002.

A third page says they're actually made of MDF under the maple veneer,
and has a photograph of the back that seems to confirm this, and a
fourth page says the manufacturer is "Takumi of Japan".

I think a handheld computer that looks like a block of wood would be
pretty nice too.  Something the size of a business card (3.5" x 2", or
89 x 51 mm) but fairly thick (say, 15mm), with veneer on at least one
side.  The resolution of the display would be limited by the light
blurring on the way through the translucent veneer; each spot of light
would have a radius on the order of the thickness of the veneer.
[Veneers are typically 0.8mm][veneers] but are available as thin as
0.3mm.

If spaced 1.6mm apart, you could get almost 1800 pixels in a
rectangular array into the business-card size.  You could do a little
better with a hexagonal array: if the distance from the center of a
regular hexagon to the center of one of its sides is r, then the
distance to one of its corners is about 1.15r, which is the same as
the length of each side; and its area is 1½ * 1.15r * 2r = 3.45r²,
which is 14% smaller than a square circumscribed around the same size
of circle.  In the case of r=0.8mm, you'd have 2.2mm² per pixel
instead of 2.56, so you'd get about 2000 pixels.  But then you'd have
to deal with the hexagonal array in your software.

1800 pixels is enough for about 45 letters in a traditional 5x8
single-bit-deep font, which is pretty cramped; my cheap two-year-old
US$30 cellphone has something like 65 letters'worth of space on its
display.  But it's enough to be useful.  It's a lot more than any of
the under-US-$10 devices I picked up for the "[cheap electronics
dissection project][electronics]" in 2006, and they are useful for
some things.

I don't know how easy or hard it is to populate a PC board with
1800-2000 LEDs.  I know I wouldn't want to do it by hand.

You could hollow out the middle of a block of wood with just a drill
and jigsaw; a keyhole saw or wire saw might work in place of the
jigsaw.  Cutting all the way through it would be a lot easier than
just chiseling out a hollow in one side of the block; then you'd need
to put veneer on both sides instead of just one.  To add strength and
keep it from sounding hollow, you'd probably want to pot the whole
interior with epoxy or something.

You could have a couple of finishing nails visible on one end if you
wanted to charge it through actual electrical contacts rather than
with induction.

Other Everyday Items
--------------------

You could also embed handheld computers in the following: oyster
shells; bricks; pens (I suggested this previously on kragen-tol);
ceramic tiles; beanbags, pillows, and stuffed animals (like the Chumby
and the Furby).

References
----------

[EP4117]: http://www.eagerplastics.com/4117.htm "Eager Plastics EP4117"

Eager Plastics, aka Eager Polymers, has an "[EP4117][] General Purpose
Polyester Laminating Resin" with a density of 1.11 g/cc.

[magic]: http://lists.canonical.org/pipermail/kragen-tol/2002-April/000700.html

In April 2002, I posted "[magic boxes and secret knocks][magic]" to
kragen-tol. 

[veneers]: http://www.diyinfo.org/wiki/Using_Veneers "an article on DIYinfo.org"

The article [Using Veneers][veneers] describes the different kinds of
wood veneers available today.

[electronics]: http://courageous.murch-sitaker.org/~kragen/electronics/

In 2006 I wrote a web page about my "[cheap electronics dissection
project][electronics]", where I bought a bunch of cheap electronics
and looked inside them.