Re: Is it possible that certain physical disk doesn't implement flush correctly?

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1319 bytes --]



On 2019/3/30 下午9:04, Supercilious Dude wrote:
> On Sat, 30 Mar 2019 at 13:00, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> I'm purposing to measure the execution time of flush/fsync, not write.
>>
>> And if flush takes 0ms, it means it doesn't really write cached data
>> onto disk.
>>
> 
> That is correct. The controller ignores your flush requests on the
> virtual disk by design. When the data hits the controller it is
> considered "stored" - the physical disk(s) storing the virtual disk is
> an implementation detail. The performance characteristics of these
> controllers are needed to make big arrays work in a useful manner. My
> controller is connected to 4 HP 2600 enclosures with 12 drives each.
> Waiting for a flush on a single disk before continuing work on the
> remaining 47 disks would be catastrophic for performance.

If controller is doing so, it must have its own power or at least finish
flush when controller writes to its fast cache.

For cache case, if we have enough data, we could still find some clue on
the flush execution time.

Despite that, for that enterprise level usage, it's OK.

But for consumer level storage, I'm not sure, especially for HDDs, and
maybe NVMe devices.

So my question still stands here.

Thanks,
Qu

> 
> Regards
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]