mirror of
https://github.com/ceph/ceph-csi.git
synced 2024-11-17 20:00:23 +00:00
rbd: do not try to run resizefs
on an encrypted BlockMode volume
When a volume has AccessType=Block and is encrypted with LUKS, a resize of the filesystem on the (decrypted) block-device is attempted. This should not be done, as the application that requested the Block volume is the only authoritive reader/writer of the data. In particular VirtualMachines that use RBD volumes as a disk, usually have a partition table on the disk, instead of only a single filesystem. The `resizefs` command will not be able to resize the filesystem on the block-device, as it is a partition table. When `resizefs` fails during NodeStageVolume, the volume is unstaged and an error is returned. Resizing an encrypted block-device requires `cryptsetup resize` so that the LUKS header on the RBD-image is updated with the correct size. But there is no need to call `resizefs` in this case. Fixes: #3945 Signed-off-by: Niels de Vos <ndevos@ibm.com>
This commit is contained in:
parent
0efe8e4711
commit
f60a358007
@ -512,6 +512,14 @@ func resizeNodeStagePath(ctx context.Context,
|
||||
if err != nil {
|
||||
return status.Error(codes.Internal, err.Error())
|
||||
}
|
||||
|
||||
// If this is a AccessType=Block volume, do not attempt
|
||||
// filesystem resize. The application is in charge of the data
|
||||
// on top of the raw block-device, we can not assume there is a
|
||||
// filesystem at all.
|
||||
if isBlock {
|
||||
return nil
|
||||
}
|
||||
}
|
||||
// check stagingPath needs resize.
|
||||
ok, err = resizer.NeedResize(devicePath, stagingTargetPath)
|
||||
|
Loading…
Reference in New Issue
Block a user