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
F101955592: D31549.diff
Tue, Nov 5, 6:56 PM
Unknown Object (File)
Wed, Oct 23, 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
Unknown Object (File)
Sep 29 2024, 7:12 AM
Unknown Object (File)
Sep 26 2024, 12:03 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

Lint
Lint Skipped
Unit
Tests Skipped

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