Add "camcontrol reprobe" subcommand, and implement it for da(4).
This makes it possible to manually force updating capacity data
after the disk got resized. Without it it might be neccessary to
reboot before FreeBSD notices updated disk size under eg VMWare.
Details
Details
- Reviewers
ken mav - Group Reviewers
manpages - Commits
- rS302376: MFC r299371 (by trasz)
rS299371: Add "camcontrol reprobe" subcommand, and implement it for da(4).
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I have some reservations for this patch. I like the functionality, and think it should be
offered. However, why do we need a 'resize' command when we already have a rescan
command? Why not make the rescan command re-do the inquiry / identify when we
pass that option to the rescan command? Why isn't ada included with this? We already
already have a CAM_EXPECT_INQ_CHANGE flag for the rescan operation. We kick off a
rescan with inq data changed flag when we get a AC_INQ_CHANGED. Why can't we
just send that instead of this new code. It would work both for scsi and ata then if
I'm reading the code right...
| sbin/camcontrol/camcontrol.8 | ||
|---|---|---|
| 526 ↗ | (On Diff #15617) | It does update the kernel data structures. This command will not re-query the drive for its information, including its size. But that begs the question, why not make rescan have an option that does a full query and updates things in the identify data changes? Why a whole new command? |
| sbin/camcontrol/camcontrol.c | ||
| 104 ↗ | (On Diff #15617) | Again, argument to rescan instead? |
| sys/cam/cam_ccb.h | ||
| 783 ↗ | (On Diff #15617) | How is this different than AC_INQ_CHANGED? Why not another way to rescan the bus? The bus rescan code already has the CAM_EXPECT_INC_CHANGED flag. At the worse, we should just be adding a CAM_EXPECT_CAPACITY_CHANGED flag as well. |
| sys/cam/scsi/scsi_da.c | ||
| 1772–1775 ↗ | (On Diff #15617) | Just da? Why not ada? Why isn't the capacity data has changed sense code for unit attention working for this? Why can't you use AC_INQ_CHANGED instead so you don't need a new AC code? |
| sbin/camcontrol/camcontrol.8 | ||
|---|---|---|
| 526 ↗ | (On Diff #15617) | From what I've seen, the "camcontrol readcap" command _does_ query the drive. As in, after you change the LUN size, "readcap" will show the updated size, but "diskinfo -v" won't. You need "camcontrol reprobe" to notify GEOM about the change. (Yes, UA works as well, see below.) As for rescan - the primary reason for this is that for reprobe, I want the device identifier, like "da0", and not bus:target:lun. It's for usability reasons: it's trivial to explain to the user how to use that with device identifier; translating it to bus:target:lun gets complicated as soon as you try to explain it in a man page. |
| sys/cam/cam_ccb.h | ||
| 783 ↗ | (On Diff #15617) | You're right about AC_INQ_CHANGED; I've modified the code to use that instead and it seems to do the trick. Note, however, that AC_INQ_CHANGED still needs to be explicitly handled by da(4). |
| sys/cam/scsi/scsi_da.c | ||
| 1772–1775 ↗ | (On Diff #15617) | I have no idea how to do it for ada(4). The ada(4) driver doesn't even contain a call to disk_resize(4), so I think it just doesn't handle resizing at all at this point. As for UA - the code does work, so if you eg. export an iSCSI lun using ctld(8) and then resize it, then the initiator will notice it "just like that" and resize itself. I believe the reason for this not working with VMWare is that VMWare just doesn't bother to send the UA. |