Very Computer

What we are doing :

on some file systems we have a lot of disk activity: creating, moving and
removing files. This action is done simulteanously by more than one process.
We are running under Solaris 7 and everything is ok that way under normal
operation. Unfortunately when the server is stopped abruptly (hardware
failure, power failure, anything else, ...) we discovered that some files
where mixed that is that one file could end with the lines that should
obviously be in an other one.

We thought that "ufs + logging" was safer than "ufs" but it is not at all
and we are very dispointed about it. Why are the files mixed after the
server has recovered. We accept them to be truncated or even to disapear but
the fact that they are mixed seems to be a problem with the file system
structure. It is the same under Solaris 8.

After some tests, "vxfs" seems to work better but it still mixes files under
heavy load. Is it true that this type of file system is not recommended if
it moves a lot (many creations and file removals) ?

We made tests under an i686 running Suse 6.4 with a "reiserfs" file system
type which is some sort of "logging" and no problem was ever produced. Isn't
Sun Solaris 7 or 8 capable of the same performance ?

--

Le site originel - The site of origins :
http://jeanmarc.launois.free.fr
Visite le, si tu l'oses... - Visit it, if you dare...

The behavior you describe is so antithetical to the kind of reliability to
which Veritas (and one would hope Sun) aspires that it makes me wonder
whether your disks might have write-back caching enabled (which would*
up either file system royally after an unclean shut-down - though why
reiserfs would remain unaffected is puzzling unless it, or Linux, disables
such operation automatically).

- bill

[Bill Todd]

Quote:>   The behavior you describe is so antithetical to the kind of
>   reliability to which Veritas (and one would hope Sun) aspires that

Yes, but this behaviour is exactly what Linux proponents have
predicted for a system which updates metadata synchronously and the
actual data blocks asynchronously.

Quote:>   it makes me wonder whether your disks might have write-back
>   caching enabled (which would*up either file system royally
>   after an unclean shut-down - though why reiserfs would remain
>   unaffected is puzzling unless it, or Linux, disables such
>   operation automatically).

Linux normally disables write-back caching on IDE-drives, not 100%
sure about SCSI.  How can you tell what Solaris does?

Kjetil T.

Quote:> [Bill Todd]

> >   The behavior you describe is so antithetical to the kind of
> >   reliability to which Veritas (and one would hope Sun) aspires that

> Yes, but this behaviour is exactly what Linux proponents have
> predicted for a system which updates metadata synchronously and the
> actual data blocks asynchronously.

Which is why competently-designed log-backed file systems are careful to
coordinate meta-data updates with data updates when such problems could
occur - and why competently-designed non-log-backed file systems use other
mechanisms (such as 'soft updates') to achieve similar robustness.

I find it much easier to believe that disk-level write-back caching is
behind the behavior than that Veritas has overlooked such an obvious design
error for the past decade-plus.

- bill

Quote:

> >   it makes me wonder whether your disks might have write-back
> >   caching enabled (which would*up either file system royally
> >   after an unclean shut-down - though why reiserfs would remain
> >   unaffected is puzzling unless it, or Linux, disables such
> >   operation automatically).

> Linux normally disables write-back caching on IDE-drives, not 100%
> sure about SCSI.  How can you tell what Solaris does?

> Kjetil T.

I've never seen logging*up Jean-Marc described.
For exampel I can (Solaris 8 x86) start a pair of ide cross-channel
ufsdump/restore pipes and pull out the powercord while it's running
and have the system boot clean.

I'd look elsewhere for the problem.

Joe