Re: Hot-swap SATA and atacontrol
Next message: Hans Lambermont: "[solved] Re: 6.0 BETA1 if_ath problems"
Date: Wed, 03 Aug 2005 12:47:39 -0700
To: sthaug@nethelp.no
sthaug@nethelp.no wrote:
>>More seriously, I don't see the point in using sync(8) three times
>>consecutively, except that's an indirect method to wait for the disk
>>buffers to be flushed before powering down. Please, correct me if I'm
>>wrong.
>>
>>
>
>Also, with softupdates you are *not* necessarily certain that all buffers
>have been flushed after three sync's.
>
>
Kirk did say a long time ago that he thought 5 syncs might be enough
but I haven't heard him say that for a long time so he may have changed
his mind :-)
>Steinar Haug, Nethelp consulting, sthaug@nethelp.no
>_______________________________________________
>freebsd-current@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>
>
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Next message: Hans Lambermont: "[solved] Re: 6.0 BETA1 if_ath problems"
Relevant Pages
- Re: Hot-swap SATA and atacontrol
... except that's an indirect method to wait for the disk ... with softupdates you are *not* necessarily certain that all buffers ... To unsubscribe, ...
(freebsd-current) - Re: Larrabee delayed: anyone know whats happening?
... Do you mean that there are modern systems that *can't* easily get 90% of theoretical disk bandwidth without using massive buffers simply by using multi-buffering in system RAM? ... stage is not written to enable streaming, ...
(comp.arch) - Re: Larrabee delayed: anyone know whats happening?
... Do you mean that there are modern systems that *can't* easily get 90% of theoretical disk bandwidth without using massive buffers simply by using multi-buffering in system RAM? ... All that's required is a disk which can transfer the data for the previous request to the host and accept a subsequent request for the next data to be read while it's reading the current request's data from its platters - or issue completion notification for the previous write request and accept the data for the subsequent write request while transferring the current write request's data to its platters, capabilities present in all current SATA disks, in SCSI disks for decades, and in some disks even earlier. ...
(comp.arch) - [PATCH 2/2] ext3: add data=guarded mode
... a workqueue where the real work of updating the on disk i_size is done. ... end_io handler for buffers that are marked as guarded. ... When we start tracking guarded buffers on a given inode, ... and it also takes a reference on the buffer head. ...
(Linux-Kernel) - Re: [RFC] fsblock
... The other reasons are that supporting larger logical block sizes than PAGE_CACHE_SIZE becomes a pain if it is not done this way when the write targets a hole as that requires all pages in the hole to be locked simultaneously which would mean dropping the page lock to acquire the others that are of lower page index and to then re-take the page lock which is horrible - much better to lock all at once from the outset and the other reason is that in NTFS there is such a thing as the initialized size of an attribute which basically states "anything past this byte offset must be returned as 0 on read, i.e. it does not have to be read from disk at all, and on write beyond the initialized_size you have to zero on disk everything between the old initialized size and the start of the write before you begin writing and certainly before you update the initalized_size otherwise a concurrent read would see random old data from the disk. ... commit_write the copied pages by dirtying their buffers ...
(Linux-Kernel) |
|
