SCIENTIFIC-LINUX-USERS Archives

July 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 19 Jul 2017 22:15:05 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (21 lines)
On Wed, Jul 19, 2017 at 9:53 PM, Kevin K <[log in to unmask]> wrote:
> And, in Red Hat 7.1 (not EL) days, it was a supported journaled filesystem.  Before EXT3 was supported.
>
> EXT3, once became supported, had the advantage that many of the tools that supported EXT2 could work better with it.

ext4 expanded on it successfully and much more safely. Also, reserfsck
was *not* your friend if you ever had a hardware issue or a reiserfs
bug. it tended to evaporate files without leaving any trace of them
anywhere, and pretend it was entirely your fault. Much, like Hans
Reiser at his murder trial, it presented sensible but obviously false
excuses for why the content was gone and where it had wound up.

It was very useful for proxies and repositories of information such as
Usenet feeds, where the presence of an individual did not matter and
would be auto-repaired, and where performance with many thousands of
files in a single directory was critical. Not so good for records you
cared about keeping intact, such as Subversion repositories or any
cataloged information without *very* careful handling of split brain
across multiple repositories, and *not* your friend for file based
databases with lots of small individual files that you cared about.

ATOM RSS1 RSS2