12 May
2020
12 May
'20
12:51 p.m.
I would also like to add that the OSDs can (and will) use redirect on write
techniques (not to mention the physical device hardware as well).
Therefore, your zeroing of the device might just cause the OSDs to allocate
new extents of zeros while the old extents remain intact (albeit
unreferenced and available for future writes). The correct solution would
be to layer LUKS/dm-crypt on top of the RBD device if you need a strong
security guarantee about a specific image, or use encrypted OSDs if the
concern is about the loss of the OSD physical device.
On Tue, May 12, 2020 at 6:58 AM Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote:
dd if=/dev/zero of=rbd ???? :) but if you have encrypted osd's, what
would be the use of this?
-----Original Message-----
From: huxiaoyu(a)horebdata.cn [mailto:huxiaoyu@horebdata.cn]
Sent: 12 May 2020 12:55
To: ceph-users
Subject: [ceph-users] Zeroing out rbd image or volume
Hi， Ceph folks,
Is there a rbd command, or any other way, to zero out rbd images or
volume? I would like to write all zero data to an rbd image/volume
before remove it.
Any comments would be appreciated.
best regards,
samuel
Horebdata AG
Switzerland
huxiaoyu(a)horebdata.cn
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an
email to ceph-users-leave(a)ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
--
Jason
12 May
12 May
12:54 p.m.
New subject: Zeroing out rbd image or volume
And many hypervisors will turn writing zeroes into an unmap/trim (qemu
detect-zeroes=unmap), so running trim on the entire empty disk is often the
same as writing zeroes.
So +1 for encryption being the proper way here
Paul
--
Paul Emmerich
Looking for help with your Ceph cluster? Contact us at https://croit.io
croit GmbH
Freseniusstr. 31h
81247 München
www.croit.io
Tel: +49 89 1896585 90
On Tue, May 12, 2020 at 1:52 PM Jason Dillaman <jdillama(a)redhat.com> wrote:
I would also like to add that the OSDs can (and will)
use redirect on write
techniques (not to mention the physical device hardware as well).
Therefore, your zeroing of the device might just cause the OSDs to allocate
new extents of zeros while the old extents remain intact (albeit
unreferenced and available for future writes). The correct solution would
be to layer LUKS/dm-crypt on top of the RBD device if you need a strong
security guarantee about a specific image, or use encrypted OSDs if the
concern is about the loss of the OSD physical device.
On Tue, May 12, 2020 at 6:58 AM Marc Roos <M.Roos(a)f1-outsourcing.eu>
wrote:
dd if=/dev/zero of=rbd ???? :) but if you have encrypted osd's, what
would be the use of this?
-----Original Message-----
From: huxiaoyu(a)horebdata.cn [mailto:huxiaoyu@horebdata.cn]
Sent: 12 May 2020 12:55
To: ceph-users
Subject: [ceph-users] Zeroing out rbd image or volume
Hi， Ceph folks,
Is there a rbd command, or any other way, to zero out rbd images or
volume? I would like to write all zero data to an rbd image/volume
before remove it.
Any comments would be appreciated.
best regards,
samuel
Horebdata AG
Switzerland
huxiaoyu(a)horebdata.cn
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an
email to ceph-users-leave(a)ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
--
Jason
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
1:03 p.m.
New subject: Zeroing out rbd image or volume
On 5/12/20 1:54 PM, Paul Emmerich wrote:
And many hypervisors will turn writing zeroes into an
unmap/trim (qemu
detect-zeroes=unmap), so running trim on the entire empty disk is often the
same as writing zeroes.
So +1 for encryption being the proper way here
+1
And to add to this: No, a newly created RBD image will never have 'left
over' bits and bytes from a previous RBD image.
I had to explain this multiple times to people which were used to old
(i)SCSI setups where partitions could have leftover data from a
previously created LUN.
With RBD this won't happen.
Wido
>
> Paul
>
4:54 p.m.
New subject: Zeroing out rbd image or volume
thanks a lot for all. Looks like dd zero does not help much about improving security, but
OSD encryption would be sufficent.
best regards,
Samuel
huxiaoyu(a)horebdata.cn
From: Wido den Hollander
Date: 2020-05-12 14:03
To: Paul Emmerich; Dillaman, Jason
CC: Marc Roos; ceph-users
Subject: [ceph-users] Re: Zeroing out rbd image or volume
On 5/12/20 1:54 PM, Paul Emmerich wrote:
And many hypervisors will turn writing zeroes into an
unmap/trim (qemu
detect-zeroes=unmap), so running trim on the entire empty disk is often the
same as writing zeroes.
So +1 for encryption being the proper way here
+1
And to add to this: No, a newly created RBD image will never have 'left
over' bits and bytes from a previous RBD image.
I had to explain this multiple times to people which were used to old
(i)SCSI setups where partitions could have leftover data from a
previously created LUN.
With RBD this won't happen.
Wido
Paul
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
19 May
19 May
5:58 p.m.
New subject: Zeroing out rbd image or volume
On Tue, May 12, 2020 at 6:03 AM Wido den Hollander <wido(a)42on.com> wrote:
And to add to this: No, a newly created RBD image will
never have 'left
over' bits and bytes from a previous RBD image.
I had to explain this multiple times to people which were used to old
(i)SCSI setups where partitions could have leftover data from a
previously created LUN.
With RBD this won't happen.
Do we have this written down in our Ceph documentation anywhere? I was
searching for an official statement about this but I could not find
it.
- Ken
1460
days inactive
1467
days old
4 comments
5 participants
participants (5)
-
huxiaoyu＠horebdata.cn -
Jason Dillaman -
Ken Dreyer -
Paul Emmerich -
Wido den Hollander