Erik Trulsson wrote:
Oliver Fromme wrote:
Christopher Sean Hilton wrote:
Please understand that this is an honest question but isn't that true
only of IDE heritage drives. E.g. If a SCSI drive with Tagged Queuing
says that the the bits have been written doesn't it mean that the
On Thu, Nov 30, 2006 at 01:42:35PM +0100, Oliver Fromme wrote:
Erik Trulsson wrote:
Oliver Fromme wrote:
Christopher Sean Hilton wrote:
Please understand that this is an honest question but isn't that true
only of IDE heritage drives. E.g. If a SCSI drive with Tagged Queuing
Christopher Sean Hilton wrote:
Kevin Oberman wrote:
[ ... ]
The magic phrase is buffer cache has been flushed. In the real world
of discs with cache there is no way to be certain when the data is
REALLY on the disc. That is why things get clobbered if the power is
cycled to the
On Wed, Nov 29, 2006 at 05:07:01PM +0100, Oliver Fromme wrote:
Christopher Sean Hilton wrote:
Kevin Oberman wrote:
[ ... ]
The magic phrase is buffer cache has been flushed. In the real world
of discs with cache there is no way to be certain when the data is
REALLY on the disc.
On Tue, Nov 28, 2006 at 12:18:03AM +0100 I heard the voice of
O. Hartmann, and lo! it spake thus:
Ronald Klop wrote:
IMHO: Please discuss this on [EMAIL PROTECTED] And read
the handbook (http://www.freebsd.org/handbook) about
releases/versions/branches. -CURRENT is known to have bugs.
I
On Nov 27, 2006, at 8:41 AM, Kevin Oberman wrote:
As far as I know, that's not different from calling sync
just once. It might make more sense to put a little sleep
between the sync calls, though.
The traditional mantra was
sync
sync
sync
and not sync;sync;sync. The reason was timing. By
From: Chuck Swiger [EMAIL PROTECTED]
Date: Tue, 28 Nov 2006 11:36:52 -0800
On Nov 27, 2006, at 8:41 AM, Kevin Oberman wrote:
As far as I know, that's not different from calling sync
just once. It might make more sense to put a little sleep
between the sync calls, though.
The
On Nov 28, 2006, at 2:36 PM, Chuck Swiger wrote:
The other choice would be to make sync [or the sync(2) system call,
more precisely] blocking, so that it does not return until the
buffer cache has been flushed and all dirty pages in VM have been
written to disk.
I would love a flag to
On Tue, 2006-11-28 at 11:51 -0800, Kevin Oberman wrote:
[ ... ]
The magic phrase is buffer cache has been flushed. In the real world
of discs with cache there is no way to be certain when the data is
REALLY on the disc. That is why things get clobbered if the power is
cycled to the disc too
O. Hartmann wrote:
Maybe amd() dismounts to early ... Don't know. Maybe the magic
'sync;sync;sync' before dismounting will help, I'll try it.
As far as I know, that's not different from calling sync
just once. It might make more sense to put a little sleep
between the sync calls, though.
Date: Mon, 27 Nov 2006 14:53:06 +0100 (CET)
From: Oliver Fromme [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
O. Hartmann wrote:
Maybe amd() dismounts to early ... Don't know. Maybe the magic
'sync;sync;sync' before dismounting will help, I'll try it.
As far as I know, that's not
I realise the original posting was related to amd(8) and NFS is not a
normal filesystem but in the interest of trying to stamp out this myth...
On Mon, 2006-Nov-27 08:41:19 -0800, Kevin Oberman wrote:
The traditional mantra was
sync
sync
sync
...
That mantra is about 25 years old, so its validity
On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of
Peter Jeremy, and lo! it spake thus:
All current Un*x filesystems will automatically flush all buffers as
part of the unmount process
That Depends(tm), partly on what you mean by 'unmount'.
With my Nov05 and Jun06 -CURRENT's, I
On Mon, 27 Nov 2006 21:19:40 +0100, Matthew D. Fuller
[EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of
Peter Jeremy, and lo! it spake thus:
All current Un*x filesystems will automatically flush all buffers as
part of the unmount process
That
Ronald Klop wrote:
On Mon, 27 Nov 2006 21:19:40 +0100, Matthew D. Fuller
[EMAIL PROTECTED] wrote:
On Tue, Nov 28, 2006 at 05:37:58AM +1100 I heard the voice of
Peter Jeremy, and lo! it spake thus:
All current Un*x filesystems will automatically flush all buffers as
part of the unmount
On Sat, Nov 25, 2006 at 05:08:03PM +0100, O. Hartmann wrote:
A while ago since now I receive kernel messages like this in FreeBSD
6.2-PRE/AMD64:
fsync: giving up on dirty
0xff000362c7c0: tag devfs, type VCHR
usecount 1, writecount 0, refcount 325 mountedhere 0xff00504d8400
A while ago since now I receive kernel messages like this in FreeBSD
6.2-PRE/AMD64:
fsync: giving up on dirty
0xff000362c7c0: tag devfs, type VCHR
usecount 1, writecount 0, refcount 325 mountedhere 0xff00504d8400
flags ()
v_object 0xff00013c80e0 ref 0 pages 1286
lock
On Sat, Nov 25, 2006 at 05:08:03PM +0100, O. Hartmann wrote:
A while ago since now I receive kernel messages like this in FreeBSD
6.2-PRE/AMD64:
fsync: giving up on dirty
0xff000362c7c0: tag devfs, type VCHR
usecount 1, writecount 0, refcount 325 mountedhere 0xff00504d8400
18 matches
Mail list logo
