DragonFly kernel List (threaded) for 2008-01
DragonFly BSD
DragonFly kernel List (threaded) for 2008-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Naive HAMMER question

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Tue, 15 Jan 2008 22:51:30 +0000

Matthew Dillon wrote:
:The character encoding has to be specified somewhere.  Do we envision
:having differently encoded filenames on the same filesystem?  Filenames
:that are encoded differently than the contents of the file itself?  Does
:the filesystem need to know if a file's contents even have an encoding?
:I'm sure these are very old questions, but I know little about how file-
:systems are designed because I've never designed one (and I'm glad :o)

    My personal opinion is with Bill on this one... the filesystems, and
    possibly even the kernel, should just be neutral about the whole mess
    and allow (or at least not disallow) binary encodings, which is pretty
    much how it works now.

Carrying encoding deeper than it otherwise needs to be also adds a great deal of work to insure consistency. That need is pervasive and never-ending.

Such overhead is avoidable if the lower levels remain as pure-binary and usage-agnostic as possible.

'Lazy is good' on this score, because it puts up fewer barriers to change, and imposes lighter restrictions on apps and userlandd.

    At most I see having a kernel layer to help userland support encodings
    but I don't see the filesystem having one, and I don't see either the
    kernel or the filesystem doing anything sophisticated.

Matthew Dillon <dillon@backplane.com>

As to the fs side - have a look here (imperfect - but handy):


Note - page down - that most 'modern' fs allow a directory name to include:

'any valid byte but null'

A few allow 'any valid unicode but null' [1]

Fewer still allow 'any valid unicode' (implying null included?). [2]

What does HAMMER actually need to keep it flexible, 'grow-able' and compatible with file transfers?


[1] UTF8 originated with Plan 9, became far more widely used than the OS itself - but seems to have had no visible affect on the fortunes of Plan9 per se.

[2] Not clearly shown on that page, but ISTR that is Apple's current 'hfs' and 'hfs+', NOT Apple's original 'hfs', nor is it HP's similarly-named-but-different 'HFS'.

Ironically, I can't test it on MY Mac's as '*BSD'ie that I am, my first act in OS X setup is to reformat the drives to all-UFS....

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]