This is a discussion on Re: Is the fsync() fake on FreeBSD6.1? - FreeBSD ; On Wed, 28 Jun 2006, Ivan Voras wrote: > Bruce Evans wrote: > >>> But I see strange results with iostat. It shows 16KB transactions, ~2900 >>> tps and 46 MB/s. On the other hand, the program runs for ~36 ...
On Wed, 28 Jun 2006, Ivan Voras wrote:
> Bruce Evans wrote:
>>> But I see strange results with iostat. It shows 16KB transactions, ~2900
>>> tps and 46 MB/s. On the other hand, the program runs for ~36 seconds,
>>> which gives ~1390 tps (this is a single desktop drive). Since 36 seconds
>>> of 46MB/s would result in a file 1.6 GB in size, while it's clearly
>>> 50000*512=25MB, iostat is lying.
>> This is because you fsync() every 512 bytes. The file system then writes
>> a 16K inode block and a 16K data block, giving 64 times as much i/o as
> Ok, so you're saying that it actually does 46MB/s, rewriting 16K FS blocks
> over and over?
Yes. It's actually surprising that the speed is only 46MB/s if the drive
caches the write.
> In that case, wouldn't all writes to the FS, especially with soft-updates be
> minimally 16K+16K? It doesn't look like it when I monitor a live server -
> there are 8KB and 4KB writes... maybe UFS fragments complicate the
Yes, the minimum i/o size is the fragment size, and the average file size
is still probably smaller than 16K. However, for sequential writes to
large files, most writes should be 64K+0K (DFLTPHYS+0K) or 128K+0K
(MAXPHYS+0K) depending on how broken MAXPHYS vs MINPHYS is. Clustering
combines 16K-blocks into either 64K or 128K-blocks, and at least without
soft updates and without sync mounting or fsync(), inode updates are
normally delayed longer than data updates.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"