Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
[opensuse] Re: experiences with bache / logic of caching
Anton Aylward wrote:
I agree that caching can be non-trivial. As for write caching, bcache
also supports writethrough.

I'd prefer to use that :-)
----
LSI has had small-ish caches (512MB-1G) for years on their RAID
boards that had the option of either -- as well as
an auto-switching between the two based on the onboard
battery's status (it's frequently tested and temperature
monitored) -- when it goes through a complete recondition &
test cycle, it disables the WB automatically, and re-enables it
when the test is done and the battery is recharged.

I usually use the forced-WB & on-disk caches as well due
to the system being on a UPS -- which is usually good for
30-60 minutes before it will try to force an "orderly shutdown".
(For the rare, longer, outages, I've I can run generators,
but it's been years since I really needed them). As for
file system safety -- xfs has the concept of "write-barriers"
to allow enforcing write-ordering for safety -- that default
to assuming they are not present (the safe option if you don't
have battery backup and/or UPS backed power).
I set the barrier option on my "work disk" where there is alot
of writing (like "/home" or my "squid-cache", that either
are backed up daily (/home) or wouldn't cause too much pain
if they had to be recreated (cache partitions). Of course
that's not something you can do on most new, default linux
setups that like to put everything on 1 partition.

I hope so!
IIR there was even one rather more savvy cache manufacturer on the SCO
days who had a batter backup on the cache board.
---
Dunno about the one you mention, but LSI still does -- and
goes through extensive methods to ensure disk safety -- including
configurable background "Patrol" reads to look for decayed disk
bits that can be rebuilt from RAID redundancies.



I don't think they
fared any better. Call me a cynic, but I still think that the order of
the writes, or honouring the order that the OS and file system designers
think the ordering of the writes should be, does matter.
---
They are. That's why more modern file systems are giving the option of write-through or write-back and barriers to
the users that allows the potential of safety and speed depending
on your HW and needs. While XFS was the first with such options,
I think ext3/4 and jfs (among others) also have such options.

Now historically, one of the changes from classical V6 UNIX to classical
V7 UNIX back in the 1970s was that the file system changed the order of
the writes to preserve the structural integrity. Data was written to
the disk before the metadata and pointers. I won't go into why that
ensured that FSCK could work properly, google for that yourself. But it
is important that it was done that way.
---
Interesting, since, the file-system structure, these days, on
file-systems that don't need or have an "fsck", is now held in the
meta-data that is written to the journal -- before data is committed
to diskmeta data. Writing the data to disk 1st, resulted in greater
data savings at the cost of different people getting other people's
data in their files. That was considered bad for "security", so
now disk-blocks are meta-allocated 1st -- and only when valid data
has been written into them can they be read-directly. Otherwise,
newly-allocated space is flagged as needing to be "zeroed" before
a user can read it. If they "write" to it first, (and never read
it, the blocks don't need zeroing). But that's why the barriers
exist -- they need to record the allocated blocks and mark them
as needing cleaning 1st, which they do in the journal, so the next
time the file system is mounted, it first "replays" any journal
part so the FS-structure on disk remains integrous. Writing
the data 1st leads to lots of problems with blocks marked used, but
not attached to anything, or marked allocated, but not cleaned yet,
so users would come up with fragments (or complete copies) of other people's sensitive data.
-l
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups