3 ms·

It's a point in time write barrier no? Everything before the sync has to get written. But writes are still getting added after the sync. Maybe I'm wrong but it

It's a point in time write barrier no? Everything before the sync has to get written. But writes are still getting added after the sync. Maybe I'm wrong but it seems like sync has to not try to sync those latecomers, because otherwise it might run forever, with new writes showing up each time it waits for current writes to sync. Assuming the above is true, it makes sense to sync multiple times. You converge towards being fully synced. The first sync might take extra long (say 30s) because there could be tons of stuff unsynced. But the next sync should only have those 30s worth of writes to sync. Let's say that takes 5s. Now the third sync only has 5s worth of writes to sync, and that takes 1s... This is all built on some assumptions about how sync works. But it feels like sync needs to be able to terminate & these assumptions are the only thing I can imagine that makes sure sync can ever finish, without never ending changes keeping it open.

mike_hock 3y ago
> It's a point in time write barrier no That's the only way it makes sense. The caller controls when they start the sync, so they can make sure that all writes they care about have been issued by then. But it's impossible to define a temporal ordering between writes and the time the sync completes. That's not a well-defined point in time. There's always a non-zero delay between the time the sync proper completes and the caller gets back control.
zabzonk 3y ago
> The first sync might take extra long (say 30s) because there could be tons of stuff unsynced. that would have to be an awful lot of data, or a very slow drive, perhaps a floppy? your other assumptions are sensible, to an extent. but way back when, we typically had a script that sent a message to all ttys saying "system going down in 30 seconds, please log off" - in fact ALL the other systems i used back then (Dec10, VAX, IBM 4381) did this before the sync (or whatever they did).
- jandrese 3y ago
  I’ve seen extreme sync times when writing large files to an old slow USB thumb drive. Often you will see the first part of the copy run at full USB speed but then it slows to a crawl. Then the unmount (which does a sync) pays back that initial burst of speed. I’ve seen it take more than 5 minutes (a kernel warning about the slow sync appears in dmesg after 300 seconds IIRC).
- mike_hock 3y ago
  Don't you have any shitty ass USB sticks that only do ~6MB/s writes? 180MB worth of dirty pages is nothing.
  - bayindirh 3y ago
    Only 6MB/sec? That would be lightning fast when I first started to use USB flash drives. I have used USB 1.1 drives which are rated a mind boggling ~900kB/sec sustained transfer speeds. Good Kingstons did 5MB/sec, top of the line ones did 11MB/sec.
- rektide 3y ago
  In any production machine, I would strive very much to avoid this circumstance, yes. Better tune your system. Either allow less dirty data in the first place (dirty_background_ratio defaults to 15% of memory... even if you have 2TB of ram) or lower your dirty_writeback_centisecs so not as many seconds of dirty writes get buffered if this happening, pretty please. My example used more illustrative than real numbers. Still, 10s seems not totally uncommon, which is only 3x off.
ilyt 3y ago
You're supposed to close applications (at least ones that you cares about) then sync. Then by definition nothing important falls into the queue Also I'm around 70% sure remounting system readonly does equivalent of sync & not allow more writes.
js2 3y ago
Apparently it is not, or at least, it wasn't, once, if you believe this research: https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reb...
- rektide 3y ago
  The post says BSD tried to do what I said. And it failed to actually do it right, as basically a bug. And needed to be updated to do what I said. Which took a couple decades to find out & make happen but was a bit of an issue. Still no confirm or deny on Linux. I was at +2 and now 0 after this post rose to the top. Am I bitter? No...

mike_hock 3y ago

> It's a point in time write barrier no That's the only way it makes sense. The caller controls when they start the sync, so they can make sure that all writes they care about have been issued by then. But it's impossible to define a temporal ordering between writes and the time the sync completes. That's not a well-defined point in time. There's always a non-zero delay between the time the sync proper completes and the caller gets back control.

zabzonk 3y ago

> The first sync might take extra long (say 30s) because there could be tons of stuff unsynced. that would have to be an awful lot of data, or a very slow drive, perhaps a floppy? your other assumptions are sensible, to an extent. but way back when, we typically had a script that sent a message to all ttys saying "system going down in 30 seconds, please log off" - in fact ALL the other systems i used back then (Dec10, VAX, IBM 4381) did this before the sync (or whatever they did).

jandrese 3y ago
I’ve seen extreme sync times when writing large files to an old slow USB thumb drive. Often you will see the first part of the copy run at full USB speed but then it slows to a crawl. Then the unmount (which does a sync) pays back that initial burst of speed. I’ve seen it take more than 5 minutes (a kernel warning about the slow sync appears in dmesg after 300 seconds IIRC).
mike_hock 3y ago
Don't you have any shitty ass USB sticks that only do ~6MB/s writes? 180MB worth of dirty pages is nothing.
- bayindirh 3y ago
  Only 6MB/sec? That would be lightning fast when I first started to use USB flash drives. I have used USB 1.1 drives which are rated a mind boggling ~900kB/sec sustained transfer speeds. Good Kingstons did 5MB/sec, top of the line ones did 11MB/sec.
rektide 3y ago
In any production machine, I would strive very much to avoid this circumstance, yes. Better tune your system. Either allow less dirty data in the first place (dirty_background_ratio defaults to 15% of memory... even if you have 2TB of ram) or lower your dirty_writeback_centisecs so not as many seconds of dirty writes get buffered if this happening, pretty please. My example used more illustrative than real numbers. Still, 10s seems not totally uncommon, which is only 3x off.

ilyt 3y ago

You're supposed to close applications (at least ones that you cares about) then sync. Then by definition nothing important falls into the queue Also I'm around 70% sure remounting system readonly does equivalent of sync & not allow more writes.

js2 3y ago

Apparently it is not, or at least, it wasn't, once, if you believe this research: https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reb...

rektide 3y ago
The post says BSD tried to do what I said. And it failed to actually do it right, as basically a bug. And needed to be updated to do what I said. Which took a couple decades to find out & make happen but was a bit of an issue. Still no confirm or deny on Linux. I was at +2 and now 0 after this post rose to the top. Am I bitter? No...