Page MenuHomeFreeBSD

Don't sync DAs if reboot type is RB_NOSYNC
ClosedPublic

Authored by wma on Aug 16 2021, 5:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Dec 3, 6:13 PM
Unknown Object (File)
Nov 18 2024, 10:08 PM
Unknown Object (File)
Nov 5 2024, 6:56 PM
Unknown Object (File)
Oct 23 2024, 7:38 PM
Unknown Object (File)
Oct 3 2024, 8:50 PM
Unknown Object (File)
Oct 2 2024, 5:21 AM
Unknown Object (File)
Oct 1 2024, 2:30 AM
Unknown Object (File)
Oct 1 2024, 12:34 AM
Subscribers
None

Details

Summary

Do not iterate through device list doing 'sync'

if NOSYNC reboot method is explicitly chosen.

Calling sync may cause additional panic on dodump if the panic
was first originated from USB/SCSI layer.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

wma requested review of this revision.Aug 16 2021, 5:38 AM

The description is wrong, or at least ambiguous. This has nothing to do with sync(2), but instead avoids sending any SCSI commands to the drive, specifically, the SCSI SYNCHRONIZE CACHE command for the open devices.

Since there's two different kinds of sync here, the ambiguity is confusing. I'd recommend:

cam: don't send scsi commands on shutdown when reboot method RB_NOSYNC

Don't send the SCSI comand SYNCHRONIZE CACHE on devices that are still
open when RB_NOSYNC is the reboot method. This may avoid recursive panics
when doadump is called due to a SCSI/CAM/USB error/bug.

Though it would be better to know which of the devices would cause the
problem because you *DO* want to send it to all the other devices as
this can lead to data loss. Since I'm unsure what scenarios would cause
the data loss, I'm not ticking the 'accept change' box to give others a
chance to chime in.

Thanks for comment, yes, the description might have been misleading.

@all Any objections to commit this patch?

This revision is now accepted and ready to land.Dec 13 2021, 5:37 AM