On 18 Jul, Matthias Buelow wrote:
Paul Mather [EMAIL PROTECTED] writes:
Why would that necessarily be more successful? If the outstanding
buffers count is not reducing between time intervals, it is most likely
because there is some underlying hardware problem (e.g., a bad block).
If the count
On 16 Jul, David Taylor wrote:
On Sat, 16 Jul 2005, Matthias Buelow wrote:
David Taylor [EMAIL PROTECTED] writes:
A corrupted journal can be detected. If it's corrupted, discard
the whole thing, or only the relevant entry. The filesystem will
remain consistent.
If track corruption
On 14 Jul, Matthias Buelow wrote:
Kevin Oberman wrote:
How can I fix it on my system?
SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or
the sysctl.
You do NOT want to do that. Not only will performance drop brutally
(example: drop to 1/5th of normal write speed for
On 14 Jul, Kevin Oberman wrote:
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Hello, everybody!
I have found unusual and dangerous situation with shutdown process:
I did a copy of 200 GB data on the 870 GB partition
Kevin Oberman [EMAIL PROTECTED] wrote:
[...]
I believe that the Windows solution to this problem is to put a really,
really long delay between when the system is finished syncing and when
the power is turned off.
Definitely not. When I compare Windows XP and FreeBSD on
the same hardware
Matthias Buelow [EMAIL PROTECTED] wrote:
Sorry folks, have I somehow dropped into a parallel universe,
or is there some serious misunderstanding going on?
Seems so.
To the OP: There is no sync process that is being killed by
shutdown
Yes, there is a kernel process called syncer. During
Oliver Fromme [EMAIL PROTECTED] writes:
buffers to disk. While it is doing that, it displays the
number of remaining buffers, with increasing time intervals
between them. If there are still buffers left after a
certain number of intervals without change, the kernel
gives up.
Why is it doing
On Mon, 2005-07-18 at 16:35 +0200, Matthias Buelow wrote:
Oliver Fromme [EMAIL PROTECTED] writes:
buffers to disk. While it is doing that, it displays the
number of remaining buffers, with increasing time intervals
between them. If there are still buffers left after a
certain number of
Paul Mather [EMAIL PROTECTED] writes:
Why would that necessarily be more successful? If the outstanding
buffers count is not reducing between time intervals, it is most likely
because there is some underlying hardware problem (e.g., a bad block).
If the count still persists in staying put, it
Matthias Buelow [EMAIL PROTECTED] wrote:
Oliver Fromme [EMAIL PROTECTED] writes:
buffers to disk. While it is doing that, it displays the
number of remaining buffers, with increasing time intervals
between them. If there are still buffers left after a
certain number of intervals
Matthias Buelow [EMAIL PROTECTED] writes:
Lowell Gilbert wrote:
Well, break it down a little bit. If an ATA drive properly implements
the cache flush command, then none of the ongoing discussion is
Are you sure this is the case? Are there sequence points in softupdates
where it issues a
On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote:
Paul Mather [EMAIL PROTECTED] writes:
Why would that necessarily be more successful? If the outstanding
buffers count is not reducing between time intervals, it is most likely
because there is some underlying hardware problem (e.g.,
Oliver Fromme wrote:
Definitely not. When I compare Windows XP and FreeBSD on
the same hardware (notebook with ATA disk), then Windows'
shutdown process is a lot faster than FreeBSD's. In fact,
when I shut it down under XP for the first time, the power
was off so quickly that I thought
Comment from out in left field --
On 2005/07/16, at 6:03, Kevin Oberman wrote:
[...]
I believe that the Windows solution to this problem is to put a
really,
really long delay between when the system is finished syncing and when
the power is turned off.
That's what I vote for. If the system
On Friday, 15. July 2005 21:14, Matthias Buelow wrote:
Why am I arguing in an uphill battle here?
important to the FreeBSD community? Such issues should not even
have to be discussed at all!
I completely agree, and there's really no point in arguing with people who are
happy to throw dollars
* Matthias Buelow [EMAIL PROTECTED] [2005-07-16 01:42 +0200]:
David Taylor [EMAIL PROTECTED] writes:
A corrupted journal can be detected. If it's corrupted, discard
the whole thing, or only the relevant entry. The filesystem will
remain consistent.
If track corruption occurs after the
On Sat, 16 Jul 2005, Matthias Buelow wrote:
David Taylor [EMAIL PROTECTED] writes:
A corrupted journal can be detected. If it's corrupted, discard
the whole thing, or only the relevant entry. The filesystem will
remain consistent.
If track corruption occurs after the journal is written,
Matthias Buelow wrote this message on Fri, Jul 15, 2005 at 22:11 +0200:
for write barriers in the block drivers had been implemented, we
phk removed support for write barriers because no one was making use
of them... FreeBSD had them, and when there is *CODE* that makes use
of them, they'll be
Nicolas Rachinsky wrote:
The track which is corrupted could contain data that wasn't written
to in months. How would the journal help?
I don't understand this question.
The track destroyed could contain sectors which are in no way related
to the sectors the OS is writing to.
And in what
: dangerous situation with shutdown process
To: Bill Vermillion [EMAIL PROTECTED]
Cc: freebsd-stable@freebsd.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Bill Vermillion wrote:
Copying very large files and then shutting down I hope is not a
normal procecure
* Matthias Buelow [EMAIL PROTECTED] [2005-07-16 16:07 +0200]:
Nicolas Rachinsky wrote:
The track which is corrupted could contain data that wasn't written
to in months. How would the journal help?
I don't understand this question.
The track destroyed could contain sectors which are
David Taylor wrote:
No. I'm just asking if you know of ANY ata drives that will wait for the
cache to be flushed before claiming the disable cache command has
succeeded. I don't, but I haven't looked.
I don't know either. I assume that they do. Does it matter?
I mean, I'm not suggesting a
Bill Vermillion wrote:
You can fsck a mounted file system and fsck will run in read-only
mode. That way you can check for problems, and if there is
something wrong you can shutdown and restart. FreeBSD will NOT
run fsck in anything other than READ ONLY when the file system is
mounted
I thought
At Sat, Jul 16, 2005 at 16:29 , our malformed and occasionally
flatulent friend Matthias Buelow spewed forth this fount of brain juice:
Bill Vermillion wrote:
You can fsck a mounted file system and fsck will run in read-only
mode. That way you can check for problems, and if there is
On Jul 15, 2005, at 11:08, Bill Vermillion wrote:
If you only do huge copies and immediate shutdowns rarely, then
maybe it's just a good idea to remember how softupdates work, and
then fsck, then shutdown.
This may sound simplistic, but what about a triple sync(8)? (sync;
sync; sync)
I know you'll find this hard to believe, but on Sat, Jul 16, 2005 at 10:52 ,
David Magda actually admitted to saying:
On Jul 15, 2005, at 11:08, Bill Vermillion wrote:
If you only do huge copies and immediate shutdowns rarely, then
maybe it's just a good idea to remember how softupdates
On Sat, 2005-07-16 at 16:16 +0200, Matthias Buelow wrote:
David Taylor wrote:
No. I'm just asking if you know of ANY ata drives that will wait for the
cache to be flushed before claiming the disable cache command has
succeeded. I don't, but I haven't looked.
I don't know either. I
On Jul 16, 2005, at 11:03, Bill Vermillion wrote:
Actually I saw that documented a very very long time ago in
an Intel Unix manual.
It's present in more recent documentation. :)
The sync utility can be called to ensure that all disk writes have
been
completed before the processor
Bill Vermillion said:
Actually I saw that documented a very very long time ago in
an Intel Unix manual. And Intel got out of Unix in the mid to late
1980s. I don't recall if that was the one that was sold to Kodak -
the picture people - which then was sold to Interactive ?? - and
eventually
Paul Mather [EMAIL PROTECTED] writes:
Despite that, I have never EVER had a problem with data consistency on
my file systems. (The only problem I have had is when I added an ATA
controller card one time and forgot to disable its RAID BIOS, which
promptly spammed over my geom_mirror
Rick Kelly wrote:
The main reason for sync;sync;sync on V7 UNIX was because you couldn't
do a shutdown, only a halt to the hardware monitor, on the PDP11. You
can verify that behavior with SIMH. :-)
Uhm.. that's the same on the VAX.. in what way would that preclude
a shutdown? NetBSD certainly
Paul Mather wrote:
on reboot. (Actually, what I find to be more inconvenient is the
resynchronisation time needed for my geom_mirror, which takes a lot
longer than a fsck.) I understand that fsck delays for large file
systems is the major impetus behind the journalling work, not as a fix
for a
Lowell Gilbert wrote:
Well, break it down a little bit. If an ATA drive properly implements
the cache flush command, then none of the ongoing discussion is
Are you sure this is the case? Are there sequence points in softupdates
where it issues a flush request and by this guarantees fs
No, it's at a level below softupdates that this must be done. Softupdates
only understands when things have been marked completed with
biodone()--the underlying scsi/ata/sata driver must make the determination
as to when biodone should be called.
The flush has to be done there. _IF_ the flush
On Sat, 16 Jul 2005, Rick Kelly wrote:
The main reason for sync;sync;sync on V7 UNIX was because you couldn't
do a shutdown, only a halt to the hardware monitor, on the PDP11. You
can verify that behavior with SIMH. :-)
And you weren't supposed to use sync;sync;sync but this:
# sync
# sync
Am Freitag, den 15.07.2005, 11:15 +0600 schrieb Sergey N. Voronkov:
On Thu, Jul 14, 2005 at 04:17:06PM -0400, asym wrote:
At 15:19 7/14/2005, Wilko Bulte wrote:
On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote..
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy
On Thu, Jul 14, 2005 at 22:31 , [EMAIL PROTECTED]
moved his mouse, rebooted for the change to take effect, and then
said:
Message: 13
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Subject: dangerous situation with shutdown process
To:
Matthias Buelow wrote this message on Thu, Jul 14, 2005 at 21:52 +0200:
The problem is that disks lie about whether they have actually written
data. If the power goes off before the data is in cache, it's lost.
No, the problem is that FreeBSD doesn't implement request barriers
and that
John-Mark Gurney wrote:
With non-written to sectors getting trashed with the cache enabled,
barriers don't mean squat...
Of course if you pound the disk with a hammer, then barriers also
won't help. Just because with a few disks perhaps it won't work at
all doesn't mean that one shouldn't at
John-Mark Gurney wrote:
even request barries will not save the fs in a power loss if the track
that is getting flushed durning a power loss... Some other FreeBSD
folk has a reproducable case of where blocks that were not written to
on ATA hardware got trashed after a power loss...
With
Matthias Buelow wrote:
John-Mark Gurney wrote:
[ ... ]
Why am I arguing in an uphill battle here? Is data safety no longer
important to the FreeBSD community? Such issues should not even
have to be discussed at all!
You ask a good question: so, just why are *you* arguing? [1]
If sysctl
Chuck Swiger wrote:
If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR
containing something better. Or buy SCSI hardware and a real,
Well, if I had the time, I would. Also if instead of softupdates,
a proper journalled filesystem implementation with kernel support
for write
On Fri, Jul 15, 2005 at 10:11:02PM +0200, Matthias Buelow wrote..
Chuck Swiger wrote:
If sysctl hw.ata.wc=0 doesn't do what you want, please submit a PR
containing something better. Or buy SCSI hardware and a real,
Well, if I had the time, I would. Also if instead of softupdates,
a
Matthias Buelow [EMAIL PROTECTED] writes:
The combination barriers+journal really seems to be very resilient
to filesystem corruption. When it's implemented without errors, and
the hardware doesn't do things like change bits randomly, I can't
think of a way this scheme can be corrupted at
Wilko Bulte wrote:
sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You..
Followups to /dev/null
Yes, makes no sense talking to a wall.
mkb.
___
freebsd-stable@freebsd.org mailing list
Date: Fri, 15 Jul 2005 22:24:07 +0200
From: Matthias Buelow [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Wilko Bulte wrote:
sigh Not If The Bloody PeeCee Style Crap ATA Drives Keep Lying To You..
Followups to /dev/null
Yes, makes no sense talking to a wall.
You are right, but I don't
On Fri, 15 Jul 2005, Matthias Buelow wrote:
Why am I arguing in an uphill battle here? Is data safety no longer
important to the FreeBSD community? Such issues should not even
have to be discussed at all!
I'm trying to tell you what you have to say to move forward on this issue:
1) tell
Kevin Oberman [EMAIL PROTECTED] writes:
I believe that the Windows solution to this problem is to put a really,
really long delay between when the system is finished syncing and when
the power is turned off. This might be the best solution for FreeBSD, as
well, but it will irritate people.
The
Lowell Gilbert [EMAIL PROTECTED] writes:
We keep trying to point out that barriers *can't* be enforced on the
hardware with many (most, and apparently an increasing percentage of)
ATA drives. There is no semantic on these drives that allows you to
guarantee the journal block will be written
I know my drive allows disabling of the write cache, as, apparently, the
majority of IDE/SATA drives do.
Yes fair enough. This command is in the specification as far back as
ata-1. I guess it yields reasonable? performance?
You should, however, be telling sos@ this--if he doesn't already
On Fri, 15 Jul 2005, Matthias Buelow wrote:
John-Mark Gurney wrote:
even request barries will not save the fs in a power loss if the track
that is getting flushed durning a power loss... Some other FreeBSD
folk has a reproducable case of where blocks that were not written to
on ATA
David Taylor [EMAIL PROTECTED] writes:
A corrupted journal can be detected. If it's corrupted, discard
the whole thing, or only the relevant entry. The filesystem will
remain consistent.
If track corruption occurs after the journal is written, it doesn't
matter, since at boot the journal
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Hello, everybody!
I have found unusual and dangerous situation with shutdown process:
I did a copy of 200 GB data on the 870 GB partition (softupdates is
enabled) by cp command.
On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote..
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Hello, everybody!
I have found unusual and dangerous situation with shutdown process:
I did a copy of 200 GB
Kevin Oberman wrote:
SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or
the sysctl.
The problem is that disks lie about whether they have actually written
data. If the power goes off before the data is in cache, it's lost.
I am not sure if write-cache can be turned off on
Kevin Oberman wrote:
How can I fix it on my system?
SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or
the sysctl.
You do NOT want to do that. Not only will performance drop brutally
(example: drop to 1/5th of normal write speed for sequential writes,
probably worse for
On Thu, Jul 14, 2005 at 09:52:53PM +0200, Matthias Buelow wrote:
Kevin Oberman wrote:
The problem is that disks lie about whether they have actually written
data. If the power goes off before the data is in cache, it's lost.
No, the problem is that FreeBSD doesn't implement request
softupdates is perfectly safe with SCSI.
its well known that ide and sata w/wo ncq fails to provide suitable
semantics for softupdates
however, journaling fairs no better, and request barriers do nothing to
solve the problem.
Request Barriers under linux exist to prevent the low level kernel
At 15:19 7/14/2005, Wilko Bulte wrote:
On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote..
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Hello, everybody!
I have found unusual and dangerous situation with
David Sze wrote:
Until a journalled fs that uses write request barriers is available
for FreeBSD, you better had a reliable UPS.
How do OS-level request barriers help if the disk reorders pending
writes in its cache?
By separating journal updates from the corresponding metadata (and/or
data)
Jon Dama wrote:
Request Barriers under linux exist to prevent the low level kernel block
device layer from reordering write operations from the upper file system
layers. Request Barriers consist of nothing more than tagging internal
queues within the Linux kernel itself. They do nothing to
if the FUA bit in the sata command header is properly respected.
if the flush cache command on an ata device is properly respected.
if the flush cache command on an ata device is implemented (it's optional)
if the flush cache command exists when the ata device was made (it isn't
in the earlier
Jon Dama [EMAIL PROTECTED] writes:
if the FUA bit in the sata command header is properly respected.
if the flush cache command on an ata device is properly respected.
if the flush cache command on an ata device is implemented (it's optional)
if the flush cache command exists when the ata device
Jon Dama [EMAIL PROTECTED] writes:
softupdates is perfectly safe with SCSI.
its well known that ide and sata w/wo ncq fails to provide suitable
semantics for softupdates
however, journaling fairs no better, and request barriers do nothing to
solve the problem.
I had assumed that the
Lowell Gilbert [EMAIL PROTECTED] writes:
Jon Dama [EMAIL PROTECTED] writes:
however, journaling fairs no better, and request barriers do nothing to
solve the problem.
I had assumed that the sequence of operations in a journal would be
idempotent. Is that a reasonable design criterion? [If it
On Thu, Jul 14, 2005 at 04:17:06PM -0400, asym wrote:
At 15:19 7/14/2005, Wilko Bulte wrote:
On Thu, Jul 14, 2005 at 12:14:49PM -0700, Kevin Oberman wrote..
Date: Thu, 14 Jul 2005 20:38:15 +0200
From: Anatoliy Dmytriyev [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Hello, everybody!
66 matches
Mail list logo
