:
:>So what do we do when we halt or reboot ?
:
:We unmount the file system. dounmount() calls VFS_SYNC() with the
:MNT_WAIT flag, and then (for ffs) ffs_unmount() calls ffs_flushfiles()
:or softdep_flushfiles(). I'm not sure why the latter is necessary.
:
:I don't understand this problem. syn
>So what do we do when we halt or reboot ?
We unmount the file system. dounmount() calls VFS_SYNC() with the
MNT_WAIT flag, and then (for ffs) ffs_unmount() calls ffs_flushfiles()
or softdep_flushfiles(). I'm not sure why the latter is necessary.
I don't understand this problem. sync() intent
yes and no.
the sync wheel indicates buffers to wrrite
in an order that will probably ensure that early dependencies are
satisfied before later ones, however even after being written,
a buffer might have remaining unsatisfied dependencies that
required that teh on disk and in momory version sstil
On Sun, 22 Aug 1999, Maxim Sobolev wrote:
> I do not know if it is bug or feature, but it seems that sync(8) command
> doesn't really flushing write buffers for softdep enabled f/s. IMHO this
> behavior is not very friendly for the notebooks and ATX owners because
> before putting computer into
So what do we do when we halt or reboot ?
--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED] "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
:
:But the buffer to buffer dependencies are already recorded in the
:sequence on the "sync-wheel" which the syncer daemon runs through,
:isn't it ?
:
:--
:Poul-Henning Kamp FreeBSD coreteam member
:[EMAIL PROTECTED] "Real hackers run -current on their laptop."
Only
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>:>structures used internally by softupdates are not condusive to doing a
>:>hard-sync.
>:
>:I gues sync needs to set a flag which makes the sync'er go through all
>:buckets with no delay and then wake the sync'ing process afterwards..
:>structures used internally by softupdates are not condusive to doing a
:>hard-sync.
:
:I gues sync needs to set a flag which makes the sync'er go through all
:buckets with no delay and then wake the sync'ing process afterwards...
:
:--
:Poul-Henning Kamp FreeBSD coreteam memb
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>
>It's a bug, one that I've brought up with Kirk. The problem is that the
>structures used internally by softupdates are not condusive to doing a
>hard-sync.
I gues sync needs to set a flag which makes the sync'er go through all
:I do not know if it is bug or feature, but it seems that sync(8) command
:doesn't really flushing write buffers for softdep enabled f/s. IMHO this
:behavior is not very friendly for the notebooks and ATX owners because
:before putting computer into sleep mode OS preferably should try to
:write as
I do not know if it is bug or feature, but it seems that sync(8) command
doesn't really flushing write buffers for softdep enabled f/s. IMHO this
behavior is not very friendly for the notebooks and ATX owners because
before putting computer into sleep mode OS preferably should try to
write as many
11 matches
Mail list logo
