On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> The ll_rw_block interface is perfectly clear: it expects the data to
> be written to persistent storage once the buffer_head end_io is
> called. If that's not the case, somebody needs to fix the lower
> layers.
Sure in 2.5 when I have a cleaner me
Hi,
On Tue, Feb 06, 2001 at 11:25:00AM -0800, Andre Hedrick wrote:
> On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> > No, we simply omit to instruct them to enable write-back caching.
> > Linux assumes that the WCE (write cache enable) bit in a disk's
> > caching mode page is zero.
>
> You can
On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, Feb 06, 2001 at 05:54:41PM +, David Woodhouse wrote:
> >
> > [EMAIL PROTECTED] said:
> > > Linux will obey that if it possibly can: only in cases where the
> > > hardware is actively lying about when the data has hit disk will
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Tue, Feb 06, 2001 at 02:52:40PM +, Alan Cox wrote:
> > > According to the man page for fsync it copies in-core data to disk
> > > prior to its return. Does that take async i/o to the media in account?
> > > I.e. does it wait for completion of the as
Hi,
On Tue, Feb 06, 2001 at 05:54:41PM +, David Woodhouse wrote:
>
> [EMAIL PROTECTED] said:
> > Linux will obey that if it possibly can: only in cases where the
> > hardware is actively lying about when the data has hit disk will the
> > guarantee break down.
>
> Do we attempt to ask SCS
On Tue, 6 Feb 2001, Stephen C. Tweedie wrote:
> It's worth noting that it *is* defined unambiguously in the standards:
> fsync waits until all the data is hard on disk. Linux will obey that
> if it possibly can: only in cases where the hardware is actively lying
> about when the data has hit dis
> Does this imply that in order to ensure my data hits the drives, i should
> do a warm reboot and then shut down from the lilo: prompt or similiar?
As far as I can tell the IDE drives are write caching at most a second or two
of data. Andre may know more
-
To unsubscribe from this list: send th
[EMAIL PROTECTED] said:
> Linux will obey that if it possibly can: only in cases where the
> hardware is actively lying about when the data has hit disk will the
> guarantee break down.
Do we attempt to ask SCSI disks nicely to flush their write caches in this
situation? cf. http://www.danbbs
Hello,
On Tue, 6 Feb 2001, Alan Cox wrote:
[snip]
> In theory for a journalling file system it means the change is committed to the
> log and the log to the media, and for other fs that the change is committed
> to the final disk and recoverable by fsck worst case
>
> In practice some IDE disk
Hi,
On Tue, Feb 06, 2001 at 02:52:40PM +, Alan Cox wrote:
> > According to the man page for fsync it copies in-core data to disk
> > prior to its return. Does that take async i/o to the media in account?
> > I.e. does it wait for completion of the async i/o to the disk?
>
> Undefined.
>
> According to the man page for fsync it copies in-core data to disk
> prior to its return. Does that take async i/o to the media in account?
> I.e. does it wait for completion of the async i/o to the disk?
Undefined.
In theory for a journalling file system it means the change is committed to
According to the man page for fsync it copies in-core data to disk
prior to its return. Does that take async i/o to the media in account?
I.e. does it wait for completion of the async i/o to the disk?
/Anders
PGP signature
12 matches
Mail list logo
