> :Thanks. It seems to me that for a filesystem, a block (or a fragment) is
> :the unit of I/O. Even if a single byte is modified, an entire block
> :probably consisting of multiple sectors must be written back to the disk.
> :As you said, there is no differnce whether we write this block one sec
:Thanks. It seems to me that for a filesystem, a block (or a fragment) is
:the unit of I/O. Even if a single byte is modified, an entire block
:probably consisting of multiple sectors must be written back to the disk.
:As you said, there is no differnce whether we write this block one sector
:at
> From the system's point of view, there is no difference in reliability
> between doing a single sector transfer and a multi-sector transfer
> except for the size of the retry. Since retries do not occur very often
> nobody really cares how big the retry is. Since there is a hu
:
:Thanks for your reply. I know that directory entries are physically
:prevented from crossing device block boundaries in order to ensure atomic
:update. If I write a directory file with a buffer (using some kind of
:multi-sector transfer) and do not know which sector within the buffer
:fails, w
On Tue, 2 Nov 1999, Greg Lehey wrote:
> On Tuesday, 2 November 1999 at 17:10:41 -0500, Zhihui Zhang wrote:
> >
> > It is said that the granularity of disk I/O is a sector. I read a little
> > bit of the source code isa/wd.c, which I think is the driver of IDE disks.
&g
On Tuesday, 2 November 1999 at 17:10:41 -0500, Zhihui Zhang wrote:
>
> It is said that the granularity of disk I/O is a sector. I read a little
> bit of the source code isa/wd.c, which I think is the driver of IDE disks.
> I find out that the disk can perform multi-block I/O some
It is said that the granularity of disk I/O is a sector. I read a little
bit of the source code isa/wd.c, which I think is the driver of IDE disks.
I find out that the disk can perform multi-block I/O sometimes. Does this
mean the granularity of disk I/O can be multi-sector? If the disk can
On Wed, 3 Nov 1999 11:37:42 -0800 (PST), Matthew Dillon <[EMAIL PROTECTED]>
wrote:
> The directory blocking is there for a different reason. Atomicy does not
> have much to do with it though perhaps it did at some point in the past.
Hmmm... /usr/include/ufs/ufs/dir.h states:
* A directory con
8 matches
Mail list logo