From owner-freebsd-chat  Sun Dec 14 05:11:35 1997
Return-Path: <owner-freebsd-chat@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA05579
          for chat-outgoing; Sun, 14 Dec 1997 05:11:35 -0800 (PST)
          (envelope-from owner-freebsd-chat@FreeBSD.ORG)
Received: from ns1.yes.no (ns1.yes.no [195.119.24.10])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA05554
          for <chat@freebsd.org>; Sun, 14 Dec 1997 05:11:12 -0800 (PST)
          (envelope-from eivind@bitbox.follo.net)
Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36])
	by ns1.yes.no (8.8.7/8.8.7) with ESMTP id NAA07720;
	Sun, 14 Dec 1997 13:11:06 GMT
Received: (from eivind@localhost)
	by bitbox.follo.net (8.8.6/8.8.6) id OAA12578;
	Sun, 14 Dec 1997 14:11:04 +0100 (MET)
To: Terry Lambert <tlambert@primenet.com>
Cc: chat@FreeBSD.ORG
Subject: Re: blocksize on devfs entries (and related)
References: <199712132055.NAA29304@usr06.primenet.com>
From: Eivind Eklund <perhaps@yes.no>
Date: 14 Dec 1997 14:11:03 +0100
In-Reply-To: Terry Lambert's message of Sat, 13 Dec 1997 20:55:27 +0000 (GMT)
Message-ID: <8690toqdco.fsf@bitbox.follo.net>
Lines: 42
X-Mailer: Gnus v5.4.52/XEmacs 20.2
Sender: owner-freebsd-chat@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


<Redirected to chat, which might or might not be the right place>

Terry Lambert <tlambert@primenet.com> writes:

> > > Theoretically, the physical layout of the device should be stored
> > > whether or not there's any filesystem on it.
> > 
> > This is a fundamentally flawed approach, and I am glad that Julian's 
> > new SLICE model (at this stage) completely ignores any incidental 
> > parametric information associated with an extent.
> 
> One "incidental" piece of parametric information I am interested in
> seeing is the physical block size.
> 
> Consider the FFS directory management code.  It has knowledge of
> physical blocks.  In fact, it can not easily handle a directory
> block that is not exactly a physical block size.  The current code
> can not be broken across block I/O's, nor can it handle partial
> block I/O's well (there are a number of failure modes).
> 
> This becomes *very* important if you ever want to support Unicode,
> which takes 2 characters per character, or EUC encoded "Big 5",
> which may take up to 5 characters per character (one of the reasons
> I am "for" Unicode and "against" EUC/ISO2022).

You loose.  Unicode isn't enough - the asians have introduced shifting
_anyway_, as they couldn't fit all asian languages into the space
available.

Now, if the asians hadn't voted down the original Unicode proposal
which called for selection of Unicode charsets for different asian
languages...

When you think about it, it is fairly seldom an average user need to
display multiple languages in the same document.

Eivind.

P.S. The above is based on 2nd hand "oral" information - I'm not a
nationalisation/character encoding expert, but got it off one.  So no
difficult questions now ;-)