3 Fixed grammar
source | link

No filesystems zero out blocks of deleted files, they just mark those clusters as availablemark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If theyfilesystem drivers reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry, and if they must overwrite the clusters with zero then performance will suffer severely.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like shred on Unix and ccleaner drive wiper, eraser, sdelete... on Windows to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's dynamically-sized virtual disk image format. Therefore zeroing out sectors mark them as not needed to storenot needed anymore and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be storestored explicitly because the VM doesn't know thatwhether the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofreezerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sizedfixed-sized on creation.

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If they reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like ccleaner drive wiper, eraser, sdelete... to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's virtual disk image format. Therefore zeroing out sectors mark them as not needed to store and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be store explicitly because the VM doesn't know that the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized.

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If filesystem drivers reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry, and if they must overwrite the clusters with zero then performance will suffer severely.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like shred on Unix and ccleaner drive wiper, eraser, sdelete... on Windows to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's dynamically-sized virtual disk image format. Therefore zeroing out sectors mark them as not needed anymore and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be stored explicitly because the VM doesn't know whether the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized on creation.

2 replaced http://askubuntu.com/ with https://askubuntu.com/
source | link

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If they reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder toolsshredder tools like ccleaner drive wiper, eraser, sdelete... to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's virtual disk image format. Therefore zeroing out sectors mark them as not needed to store and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be store explicitly because the VM doesn't know that the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized.

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If they reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like ccleaner drive wiper, eraser, sdelete... to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's virtual disk image format. Therefore zeroing out sectors mark them as not needed to store and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be store explicitly because the VM doesn't know that the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized.

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If they reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like ccleaner drive wiper, eraser, sdelete... to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's virtual disk image format. Therefore zeroing out sectors mark them as not needed to store and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be store explicitly because the VM doesn't know that the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized.

1
source | link

No filesystems zero out blocks of deleted files, they just mark those clusters as available. That's why recovery tools can recover deleted files if they weren't overwritten by other files. If they reuse those blocks ASAP then you'll no longer have the ability to recover accidentally erased files and customers will cry.

Files that are expected to be stored securely should be encrypted instead of leaving as-is on disk. If needed, use shredder tools like ccleaner drive wiper, eraser, sdelete... to delete securely.

About VMDK, you should know that it stores sectors in a sparse format, just like VHD, VDI or any other VM's virtual disk image format. Therefore zeroing out sectors mark them as not needed to store and the compactor will leave them out, resulting in a smaller file. Any non-zero sectors have to be store explicitly because the VM doesn't know that the sector belongs to a deleted file or not

Using dd if=/dev/zero is a bad way because

  • it is slow;
  • it makes the disk image (temporarily) grow to its maximal extent;
  • it (temporarily) uses all free space on the disk, so other concurrent write actions may fail.

as mentioned in the zerofree manpage. Use a tool specifically for zeroing out disks like zerofree instead.

There's no way to prevent a virtual disk image from expanding, because what would you expect if more data need to be written on the disk? Even in case files are deleted, their data are still on disk and take space in the image file. If you don't want the file to grow, the only way is making it fixed-sized.