Message-ID: <66aebd9e@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: Move bookworm system from SSD to NVME Newsgroups: comp.sys.raspberry-pi References: <20240801171000.46ce321a2dd0cb03be7cba00@eircom.net> <20240801192923.a827ba8d22853e9bc6c5cfb3@eircom.net> User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 4 Aug 2024 09:30:38 +1000 Organization: Ausics - https://newsgroups.ausics.net Lines: 33 X-Complaints: abuse@ausics.net Path: ...!weretis.net!feeder9.news.weretis.net!news.bbs.nz!news.ausics.net!not-for-mail Bytes: 2386 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. -- __ __ #_ < |\| |< _#