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
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
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
"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
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
> 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
[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.
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
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
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
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
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
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.
In
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 disks do
[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.
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 the
"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 async i/o to
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 the
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 not be
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
21 matches
Mail list logo
