[libvirt] [PATCH] virStorageVolWipe: Document that wiping journaled FS is useless
So you have a libvirt volume that you want to wipe out. But lets say that the volume is actually a file stored on a journaled filesystem. Overwriting it with zeroes or a pattern does not mean that corresponding physical location on the disk is overwritten too, due to journaling. It's the same story with network based volumes, copy-on-write filesystems, and so on. Since there is no way that an userland application can write onto specific areas on disk, all that we can do is document the fact. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/libvirt-storage.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 66dd9f0..513c72f 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1725,7 +1725,12 @@ virStorageVolDelete(virStorageVolPtr vol, * @vol: pointer to storage volume * @flags: extra flags; not used yet, so callers should always pass 0 * - * Ensure data previously on a volume is not accessible to future reads + * Ensure data previously on a volume is not accessible to future + * reads. Also note, that depending on the actual volume + * representation, this call may not really overwrite the + * physical location of the volume. For instance, files stored + * journaled, log structured, copy-on-write, versioned, and + * network file systems are known to be problematic. * * Returns 0 on success, or -1 on error */ @@ -1765,8 +1770,13 @@ virStorageVolWipe(virStorageVolPtr vol, * @algorithm: one of virStorageVolWipeAlgorithm * @flags: future flags, use 0 for now * - * Similar to virStorageVolWipe, but one can choose - * between different wiping algorithms. + * Similar to virStorageVolWipe, but one can choose between + * different wiping algorithms. Also note, that depending on the + * actual volume representation, this call may not really + * overwrite the physical location of the volume. For instance, + * files stored journaled, log structured, copy-on-write, + * versioned, and network file systems are known to be + * problematic. * * Returns 0 on success, or -1 on error. */ -- 2.4.10
On 12/17/2015 05:10 AM, Michal Privoznik wrote:
So you have a libvirt volume that you want to wipe out. But lets say that the volume is actually a file stored on a journaled filesystem. Overwriting it with zeroes or a pattern does not mean that corresponding physical location on the disk is overwritten too, due to journaling. It's the same story with network based volumes, copy-on-write filesystems, and so on. Since there is no way that an userland application can write onto specific areas on disk, all that we can do is document the fact.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/libvirt-storage.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
Seems reasonable. Is there an associated bz? ACK - John
diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 66dd9f0..513c72f 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1725,7 +1725,12 @@ virStorageVolDelete(virStorageVolPtr vol, * @vol: pointer to storage volume * @flags: extra flags; not used yet, so callers should always pass 0 * - * Ensure data previously on a volume is not accessible to future reads + * Ensure data previously on a volume is not accessible to future + * reads. Also note, that depending on the actual volume + * representation, this call may not really overwrite the + * physical location of the volume. For instance, files stored + * journaled, log structured, copy-on-write, versioned, and + * network file systems are known to be problematic. * * Returns 0 on success, or -1 on error */ @@ -1765,8 +1770,13 @@ virStorageVolWipe(virStorageVolPtr vol, * @algorithm: one of virStorageVolWipeAlgorithm * @flags: future flags, use 0 for now * - * Similar to virStorageVolWipe, but one can choose - * between different wiping algorithms. + * Similar to virStorageVolWipe, but one can choose between + * different wiping algorithms. Also note, that depending on the + * actual volume representation, this call may not really + * overwrite the physical location of the volume. For instance, + * files stored journaled, log structured, copy-on-write, + * versioned, and network file systems are known to be + * problematic. * * Returns 0 on success, or -1 on error. */
On 18.12.2015 20:30, John Ferlan wrote:
On 12/17/2015 05:10 AM, Michal Privoznik wrote:
So you have a libvirt volume that you want to wipe out. But lets say that the volume is actually a file stored on a journaled filesystem. Overwriting it with zeroes or a pattern does not mean that corresponding physical location on the disk is overwritten too, due to journaling. It's the same story with network based volumes, copy-on-write filesystems, and so on. Since there is no way that an userland application can write onto specific areas on disk, all that we can do is document the fact.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/libvirt-storage.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)
Seems reasonable. Is there an associated bz?
None that I know of. It's just that I've came across some discussion in the office about volWipe and it just appeared to me that we ought to have this documented. Michal
2015-12-21 10:18 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
None that I know of. It's just that I've came across some discussion in the office about volWipe and it just appeared to me that we ought to have this documented.
May be in this case doing FITRIM ioctl ? As i understand this ioctl can get minimal amount of space that needed to trim, so specify the file size we can hope that volume wiped.. -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
On 21.12.2015 11:20, Vasiliy Tolstov wrote:
2015-12-21 10:18 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
None that I know of. It's just that I've came across some discussion in the office about volWipe and it just appeared to me that we ought to have this documented.
May be in this case doing FITRIM ioctl ? As i understand this ioctl can get minimal amount of space that needed to trim, so specify the file size we can hope that volume wiped..
I'm no expert but I think fstrim is no help here - it merely reclaims free space on a disk, but raw data is still accessible. At least can be if disk does not implement DRAT (Deterministic Read After Trim) (read of zeroes that is). But better safe than sorry, right? So maybe we should issue fstrim after all. Michal
2015-12-21 13:39 GMT+03:00 Michal Privoznik <mprivozn@redhat.com>:
I'm no expert but I think fstrim is no help here - it merely reclaims free space on a disk, but raw data is still accessible. At least can be if disk does not implement DRAT (Deterministic Read After Trim) (read of zeroes that is).
But better safe than sorry, right? So maybe we should issue fstrim after all.
Yes, also trim very useful on ssd =), But i don't check does this helps or not, this is only theory. -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru
participants (3)
-
John Ferlan -
Michal Privoznik -
Vasiliy Tolstov