From: Terje Mathisen on
Jonathan Thornburg -- remove -animal to reply wrote:
> In article <pdblu3-9hh.ln1(a)> Terje Mathisen then
> commented:
>>> Case-blind case-preserving is the only variant which is acceptable from the
>>> point of view of ergonomics, IMNSHO.
>> There I agree. This obeys the principle of least surprise, but as noted
>> above, it does still have drawbacks.
> Are you saying that your idea of the POLS is that because the two
> pathnames are in the same directory, and have filenames which (let us
> say, in the current locale) compare as equal according to strcoll(3),
> then the 2nd file should overwrite the 1st? Ick.

As I said, it does have drawbacks.

Re. your particular example: BTDT. :-(

The ntpd source code CVS repository had at one point in time two
different files in the same (unix) directory, that varied only in the
case of one letter.

This was a really ugly bug when trying to compile ntpd for Windows. :-(

I still contend that a world which stops you from creating multiple
files that vary only in case would be good, but as long as we have to
coexist with file systems which doesn't, the only real solution is as
you say, i.e. to have the base filesystem be case-ignorant.


- <Terje.Mathisen(a)>
"almost all programming can be viewed as an exercise in caching"
From: Bill Todd on
Terje Mathisen wrote:


> It is _very_ obvious that even home users could/will need some form of
> sector-level data redundancy to store their digital home videos, RAW
> photos etc.

I don't think it's obvious at all. If people don't care enough to
protect against whole-disk failure by keeping backup copies, then
there's no reason to stand on our heads to try to protect against
sector-level failures. And if they *do* have backup copies, then the
rare sector-level failure (very rare indeed if background scrubbing is
employed) can be fixed from the backup data, as long as the file system
is reasonably intelligent about replicating all (or at least critical)
*metadata* in separated locations on the single disk to keep the overall
structure robust.

> So, what can be done at the single-disk level?

Aside from the metadata replication that I just mentioned above, nothing
reasonable. If people want highly-available (as contrasted with
backup-secured) access to every sector of their data, then they should
mirror it on separate disks, period.

- bill
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on
Tarjei T. Jensen <tarjei(a)> wrote:

> "Eric P." wrote:
> > - [*] For disk file system at least, I think the time for compressed
> > files has passed and are a waste of development time these days.
> Sorry content is balooning. We need everything in order to keep cost down.

File formats are usually compressed already, and you need to know the
kind of content to get the best compression.

Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on
Terje Mathisen <terje.mathisen(a)> wrote:

> Andrew Reilly wrote:
> > On Mon, 25 Sep 2006 12:52:48 +0200, Terje Mathisen wrote:
> >
> >> For every N MB of contiguous disk space, use an extra MB to store ECC
> >> info for the current block. The block size needs to be large enough that
> >> a local soft spot which straddles two sectors cannot overwhelm the ECC
> >> coding.
> >
> > Isn't that just the same as having the drive manufacturer use longer
> > reed-solomon (forward error correcting) codes? Errors at that level are
> No, because you need _huge_ lengths to avoid the problem where an areas
> of the disk is going bad. This really interferes with random access
> benchmark numbers. :-(

Whether you do it in the file system or in the drive firmware, benchmark
numbers will suck equally, don't you think?

Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on
Jan Vorbr?ggen <jvorbrueggen(a)> wrote:

> > Case-blind file systems are a pox, if you've ever had to share code across
> > filesystems, and your coleagues insist on saving headers in files with one
> > case, but some different case appears in the source of the include
> > statement...
> Say what? That is just the situation a case-blind system is designed to
> handle gracefully!

That was Andrew Reilly you quoted and I suspect that *his* filesystem is
casesensitive, so *he* gets the problem. He could just go with the flow,
of course.

Anyway, preparing diskimages with filesystems of the required
casesensitivity is an easy solution for those big balls of code that
want one flavor.

Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark