INTL 3:770/1 3:770/3
REPLYADDR not@telling.you.invalid
REPLYTO 3:770/3.0 UUCP
MSGID: <66aebd9e@news.ausics.net> a02ccfe2
REPLY: 3e560ffb
PID: SoupGate-Win32 v1.05
Bj?rn Lundin wrote:
> looking at
>
> """
> The kernel keeps data in memory to avoid doing (relatively slow) disk
> reads and writes. This improves performance, but if the computer
> crashes, data may be lost or the file system corrupted as a result. sync
> ensures that everything in memory is written to disk.
> """
>
>
> So, what I think is that dd writes to a slow device, and it is cached by
> the OS.
> sync forces the OS to actually write to slow device.
I've used the "conv=fsync" option to dd so that sync is done
automatically. Since the man page is rather vague about it, I did
a web search to double check that I wasn't imagining things and
found this page which describes the behaviour with some examples:
https://abbbi.github.io/dd/
> This may not be true with new and shiny fast NVM storage, but the
> principle holds.
The tests at that link were done with a RAM disk, and the kernel
was caching writes to that, so it doesn't look like the caching
system is smart enough to know when a device is fast enough that
the cache isn't required.
--
__ __
#_ < |\| |< _#
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
SEEN-BY: 90/1 105/81 106/201 129/305 153/757 7715 218/700 840 220/70
SEEN-BY: 221/1 6 242 360 226/17 30 100 227/114 229/110 111 200 206
SEEN-BY: 229/300 317 400 426 428 470 550 616 664 700 230/0 266/512
SEEN-BY: 267/800 280/5003 282/1038 291/111 292/854 2226 8125 301/1
SEEN-BY: 310/31 320/219 322/757 335/364 341/66 342/200 396/45 410/9
SEEN-BY: 423/81 460/58 633/280 712/848 770/1 3 100 330 340 772/210
SEEN-BY: 772/220 230 5020/400 5058/104 5075/35
PATH: 770/3 1 218/840 221/6 1 292/854 229/426
|
