Xen users - Jan 2012 - Clean deleted space in linux diks?

We''re moving to a new SAN where we can take advantage of thin
provisioning if desired. When we migrate our disks to the new SAN,
whether windows or linux, the disks consume the whole space. 

On Windows machines we can run sdelete by sysinternals on the Windows
drives, which I believe writes zeros in the deleted space. We can then
run a reclamation on the SAN disks and reclaim the deleted space. 

We run different version of SLES. Are there any similar tools for linux
or a way of doing this in linux so the deleted space can be reclaimed?

Any suggestions are appreciated.

Thanks,
James

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



James Pifer <jep@obrien-pifer.com> schrieb:
>We run different version of SLES. Are there any similar tools for linux
>or a way of doing this in linux so the deleted space can be reclaimed?
Shure, use dd or similiar tools.

If you just want to overwrite with zeros you may do a:

dd if=/dev/zero of=/dev/yourdiskorpartition

(you may speed up write by giving a larger blocksize option like i.e. bs=1024k )

if you have enough random data / fast data souce you may use that instead of
/dev/zero .

Another famous option is to encrypt the full drive and write to it - without the
key the disk content is "crap" for anyone other...

Beside this there are a lot of utilities which do that job for you - i.e.:
 http://www.thefreecountry.com/security/securedelete.shtml

btw:
On a SAN make shure that all data is written to the physical disks and not to a
cache / buffer instead (shut it down clean).

hth
cheers,


Niels.

- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8Rxcg6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDf1lAJ9YDLYHHxYZ
F65eoGxJIDF+Y4xa2QCfaobEP/UvY5l5J9sfHEBsooOkVnE=Fc0s
-----END PGP SIGNATURE-----

Niels Dettenbach (Syndicat IT&Internet) wrote:
>  >We run different version of SLES. Are there any similar tools for
linux
>>or a way of doing this in linux so the deleted space can be reclaimed?
>
>Shure, use dd or similiar tools.
>
>If you just want to overwrite with zeros you may do a:
>
>dd if=/dev/zero of=/dev/yourdiskorpartition
>
>(you may speed up write by giving a larger blocksize option like 
>i.e. bs=1024k )
>
>if you have enough random data / fast data souce you may use that 
>instead of /dev/zero .
In this case he is wanting zeros so that the SAN will make the storage sparse.

If the disk is large, it may be a bit of a problem making a single 
large file. The OP hasn''t said which specific OS (32 vs 64 bit), or 
filesystem, so I don''t know what the max file size is (I vaguely 
recall a 4G limit under some OS/filesystem combinations). He may have 
to do something like :

a=0 ; while [ $a -lt X ]
do
   dd if=/dev/zero of=null-file-$a bs=1024k count=1024
done
rm null-file*

replacing X with a value appropriate to the free space available. 
This will create 1GB files of zeros, so if there is 75G of free 
space, I''d set X to 76 just to be sure. Probably best to stop all 
unnecessary services so things don''t barf when the disk is full.


-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

> In this case he is wanting zeros so that the SAN will make the storage
sparse.
Correct.
> 
> If the disk is large, it may be a bit of a problem making a single 
> large file. The OP hasn''t said which specific OS (32 vs 64 bit),
or
> filesystem, so I don''t know what the max file size is (I vaguely 
> recall a 4G limit under some OS/filesystem combinations). 
Mostly 64 bit, but could have some 32 bit. ext3 or ext4. 
> He may have to do something like :
> 
> a=0 ; while [ $a -lt X ]
> do
>    dd if=/dev/zero of=null-file-$a bs=1024k count=1024
> done
> rm null-file*
> 
I will try this on a test box and see what happens. Any other ideas
please let me know. 

Thanks,
James

I have to admit, I''ve always wondered why FS tools don''t have
a "wipe
free space" function. While it''s easy to do it with the techniques
mentioned, I can''t help wondering if it has any knock on effects on 
the filesystem.
Does it, for example, have any impact on the number of size of free 
extents at the end of it ? Does it make some files (eg log files) 
that would otherwise be contiguous (or nearly so) get split when free 
space is almost non-existant ?

I''m guessing the answer is probably "yes, but insignificant in the
grand scheme of things".


Oh yes, if a single big file is OK, then a simpler command is :
   cat /dev/zero >bigfile ; rm bigfile

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Simon Hobson <linux@thehobsons.co.uk> schrieb:
>If the disk is large, it may be a bit of a problem making a single
>large file.
This means it is impossible to write by a device file onto that SAN to fill it?

The OP hasn''t said which specific OS (32 vs 64 bit),
or
>filesystem, so I don''t know what the max file size is (I vaguely
>recall a 4G limit under some OS/filesystem combinations). He may have
>to do something like :
>
>a=0 ; while [ $a -lt X ]
>do
>   dd if=/dev/zero of=null-file-$a bs=1024k count=1024
>done
>rm null-file*
hmmm, just to understand: this is writing onto a file system and not to a device
directly, or not?

- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8Sk/I6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDbPJAJ9zQBitVVGA
ZoH6tOEkONqTpq5WiwCbBEinyuqC2aYf1hnsfR5Qn0PzxAY=5C0L
-----END PGP SIGNATURE-----

Hi,

add in ionice -c 3 before the command; that way the command will be
run at idle priority instead of completely wrecking your performance.
(No matter if dd, cat /dev/zero or anything else is being used)

Greetings,
Florian

-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

Niels Dettenbach (Syndicat IT&Internet) wrote:
>  >a=0 ; while [ $a -lt X ]
>>do
>  >   dd if=/dev/zero of=null-file-$a bs=1024k count=1024
>>done
>>rm null-file*
>
>hmmm, just to understand: this is writing onto a file system and not 
>to a device directly, or not?
This particular command sequence will create a number of files called 
null-file-0, null-file-1, and so on. With these figures, each file 
will be 1GB in size.

If you do :
   dd if=/dev/zero of=big-null-file
then you will create a file called big-null-file which will grow 
until either the filesystem is full, or the file reaches the file 
size limit for your combination of OS and filesystem.
The same effect can be had with
   cat /dev/zero > big-null-file


In case you don''t quite get what is happening. "dd" is a
command that
copies input to output, while applying conversions (none in this 
case). "if" specifies infile, "of" specifies outfile,
"bs" specifies
block size, and "count" specifies how many blocks to copy.
So "dd if=/dev/zero of=null-file-$a bs=1024k count=1024" means : copy 
/dev/zero to null-file-<something>, use 1MByte blocks, and copy 1k of 
blocks (to get 1GByte of file).

/dev/zero is a "magic file" that just produces an infinite number of 
zeros (nulls) for as long as you read it.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Simon Hobson <linux@thehobsons.co.uk> schrieb:
>If you do :
>   dd if=/dev/zero of=big-null-file
>then you will create a file called big-null-file which will grow
aaah,

so you guys did not understand me here.

I recommended to write to the disks or SAN (not NAS) block device file (or raw
device) or partition device file (like i.e. /dev/sda ) - NOT a file onto a file
system!


hth
cheers,


Niels.
- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8TFFg6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDQedAJ9azB8Ab/5o
RWNdvL9CciqSI5vj5gCeIx8cYww91Ziw7rf/gUaqNF2fGqo=RcxB
-----END PGP SIGNATURE-----

Hello,

On Sunday 15 January 2012 09:36:19 Simon Hobson wrote:
> Oh yes, if a single big file is OK, then a simpler command is :
>    cat /dev/zero >bigfile ; rm bigfile
For Debian and ext2/ext3 file systems I would recommend a tool 
called "zerofree", which does this a little bit more clever.

Sincerely
Philipp
-- 
Philipp Hahn           Open Source Software Engineer      hahn@univention.de
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  D-28359 Bremen                 fax: +49 421 22 232-99
                                                   http://www.univention.de/


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Niels Dettenbach (Syndicat IT&Internet) wrote:
>aaah,
>
>so you guys did not understand me here.
>
>I recommended to write to the disks or SAN (not NAS) block device 
>file (or raw device) or partition device file (like i.e. /dev/sda ) 
>- NOT a file onto a file system!
Well had you written that then you''d have got the answer you need. 
You didn''t, you asked the question which we answered :
>>We''re moving to a new SAN where we can take advantage of thin
>>provisioning if desired. When we migrate our disks to the new SAN,
>>whether windows or linux, the disks consume the whole space.
>>
>>On Windows machines we can run sdelete by sysinternals on the Windows
>>drives, which I believe writes zeros in the deleted space. We can then
>>run a reclamation on the SAN disks and reclaim the deleted space.
>>
>>We run different version of SLES. Are there any similar tools for linux
>>or a way of doing this in linux so the deleted space can be reclaimed?
You asked how to wipe the **free space** (erased data) in a 
filesystem - or at least that is the best interpretation I can put on 
it. As I read that, you migrate a drive, the SAN sees old data in 
free space blocks and allocates storage for it, then you wipe the 
free space, and finally run a process on the SAN that reclaims that 
space.

So we told you how to do step 3.

If you want to erase a whole block device, then the command is much the same :
   dd if=/dev/zero of=/dev/<device>
or
   cat /dev/zero > /dev/<device>

device might be sda which will erase an entire disk including 
partition tables, raid information etc. Or it might be something like 
sda1 which will leave the partition table intact and completely erase 
the filesystem within the partition.

But I''m not sure why you''d want to do this. Surely the SAN
will thin
provision an empty volume when you first create it, and then if you 
copy files over the virtual volume will expand in physical size to 
suit. If you do this on your disk before migrating then you''ll simply 
erase all your files.

Either you are doing a block level volume copy (in which case you''ll 
need to erase free space only), or you are doing a file copy in which 
case you''ll start with an empty virtual volume which will expand in 
storage requirements as you copy files.
-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

> Either you are doing a block level volume copy (in which case
you''ll
> need to erase free space only), or you are doing a file copy in which 
> case you''ll start with an empty virtual volume which will expand
in
> storage requirements as you copy files.
Simon, 

Just to recap, I am trying to erase the free space only. I assume the
new SAN is doing a block level copy, which is why it consumes the whole
space. Once I erase the free space there is a reclamation process on the
SAN that will make the disk thin/sparse. 

Yes, if I take a newly created thin disk, and do a file level restore or
copy, the disk remains thin. 

For this example I have a disk called xvda. It has two partitions:
xvda1 (swap)
xvda2 (system)

I would like to erase the free space on xvda2, which is running on
sles11 with ext3.

Several things were mentioned. If you don''t mind repeating, what do you
feel is the final solution?

Thanks,
James

James Pifer wrote:
>  > Either you are doing a block level volume copy (in which case
you''ll
>>  need to erase free space only), or you are doing a file copy in which
>>  case you''ll start with an empty virtual volume which will
expand in
>>  storage requirements as you copy files.
>
>Simon,
>
>Just to recap, I am trying to erase the free space only. I assume the
>new SAN is doing a block level copy, which is why it consumes the whole
>space. Once I erase the free space there is a reclamation process on the
>SAN that will make the disk thin/sparse.
>
>Yes, if I take a newly created thin disk, and do a file level restore or
>copy, the disk remains thin.
>
>For this example I have a disk called xvda. It has two partitions:
>xvda1 (swap)
>xvda2 (system)
>
>I would like to erase the free space on xvda2, which is running on
>sles11 with ext3.
>
>Several things were mentioned. If you don''t mind repeating, what do
you
>feel is the final solution?
My apologies, I mixed up who said what. Niels gave you information on 
erasing an entire partition (ie nuke the entire filesystem as well), 
I gave you information on  erasing free space only.

If I were doing it, I''d do one of these :

If there''s a lot of free space and making huge files may be an issue

a=0 ; while [ $a -lt X ]
do
   dd if=/dev/zero of=null-file-$a bs=1024k count=1024
done
rm null-file*
X needs to be > amount of free space in GBytes.

If there isn''t a huge amount of free space and/or making one big file 
isn''t an issue.
dd if=/dev/zero of=null-file bs=1024k ; rm null-file
or
cat /dev/zero > null-file ; rm null-file

Both of these will write nulls into file(s) until the filesystem is 
full, then delete them. Depending on the space involved, they may 
take some time, and to avoid problems if anything tries to write a 
file while the disk is full you should stop as many processes as 
possible.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Simon Hobson <linux@thehobsons.co.uk> schrieb:
>If there''s a lot of free space and making huge files may be an
issue
>
>a=0 ; while [ $a -lt X ]
>do
>   dd if=/dev/zero of=null-file-$a bs=1024k count=1024
>done
>rm null-file*
>X needs to be > amount of free space in GBytes.
>
>If there isn''t a huge amount of free space and/or making one big
file
>isn''t an issue.
>dd if=/dev/zero of=null-file bs=1024k ; rm null-file
>or
>cat /dev/zero > null-file ; rm null-file
Yes,
and to make some further "noise" here:

If you''re paranoid and have more time you may use "shred" or
similiar tools instead of rm to remove that files with maximum security against
any forensic analysis or restorings.

If you have the option to remove files to delete with your own command you may
use shred for it instead, but i''m not shure how far shred works as
wanted on each type of SAN.

cheers,

Niels.

- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8UXYk6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDWABAJ95BDn/Qsn/
YHXX+rrih+mpACEVngCfZxmyOyjC1WTHsGHRvPJmsbpaC3U=w9i+
-----END PGP SIGNATURE-----

Hi,

regarding free space deletion there are some ext4 options to look at.
Of course using "discard" in mounting will do some good. But there is
also "discard" in mke2fs.conf which seems to zero a filesystem during
mkfs time. (Otherwise stuff might only be discarded upon deletion.

Good luck :)

Niels Dettenbach (Syndicat IT&Internet) wrote:
>If you''re paranoid and have more time you may use "shred"
or
>similiar tools instead of rm to remove that files with maximum 
>security against any forensic analysis or restorings.
I think you missed what the OP is after. All he wants is to write 
zeros to unused space so the SAN will shrink the storage space used 
(sparse provision).

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

> If there isn''t a huge amount of free space and/or making one big
file
> isn''t an issue.
> dd if=/dev/zero of=null-file bs=1024k ; rm null-file
> or
> cat /dev/zero > null-file ; rm null-file
I tried this today and although the creation and deleting of the file
worked fine, the SAN reclamation did not free any space, or make the
disk sparse/thin. I''ll let you know if something turns up with support
on the matter. 

Thanks for the help. 

James

Hi James,

2012/1/18 James Pifer <jep@obrien-pifer.com>:
>> If there isn''t a huge amount of free space and/or making one
big file
>> isn''t an issue.
>> dd if=/dev/zero of=null-file bs=1024k ; rm null-file
>> or
is your filesystem ext4 and mounted with "discard" or not?

Furthermore:
My very personal opionion - based on a few hundred servers and terabytes...
If you need something *working*, it might be worthwhile to scratch out
a few $$$$ for a Veritas license.
There is a free test version where you can find out if thin
provisioning support from your array is detected or not.


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

On Thu, Jan 19, 2012 at 5:38 AM, James Pifer <jep@obrien-pifer.com>
wrote:
>> If there isn''t a huge amount of free space and/or making one
big file
>> isn''t an issue.
>> dd if=/dev/zero of=null-file bs=1024k ; rm null-file
>> or
>> cat /dev/zero > null-file ; rm null-file
>
> I tried this today and although the creation and deleting of the file
> worked fine, the SAN reclamation did not free any space, or make the
> disk sparse/thin. I''ll let you know if something turns up with
support
> on the matter.
The big question is how does your SAN do reclamation? For example:
- Does it search for zero blocks and replace them with just pointers?
- Does it perform deduplication of some sorts?
- Does it do compression?
- Does snapshot involved here?

IIRC the easiest way to do this with zfs-based SAN is to just enable
compression, and then write zeroes. zfs will treat zero-blocks
specially, using no space at all to store them. However that only
works when there''s no snapshot/clone. If there''s snapshot, old
snapshot may still refer to the original non-zero block, thus no space
is freed until I delete the snapshot/clone.

If the SAN uses some virtual disk format (e.g. VDI, VMDK) to store
block device, the "reclamation" process must be done manually after
you zero-out the blocks.

So again, it depends on how the SAN does reclamation process.

-- 
Fajar

> IIRC the easiest way to do this with zfs-based SAN is to just enable
> compression, and then write zeroes. zfs will treat zero-blocks
> specially, using no space at all to store them. However that only
> works when there''s no snapshot/clone. If there''s
snapshot, old
> snapshot may still refer to the original non-zero block, thus no space
> is freed until I delete the snapshot/clone.
> 
> If the SAN uses some virtual disk format (e.g. VDI, VMDK) to store
> block device, the "reclamation" process must be done manually
after
> you zero-out the blocks.
> 
> So again, it depends on how the SAN does reclamation process.
I''m not exactly sure how their reclamation process works. They say I
have to zero out the space, then their reclamation should recover it. No
snapshots involved. So my question, should this command zero out the
space?
cat /dev/zero > null-file ; rm null-file

Thanks,
James

Am Donnerstag, 19. Januar 2012, 08:07:23 schrieb James
Pifer:
> So my question, should this command zero out the
> space?
> cat /dev/zero > null-file ; rm null-file
Just from the view by / over the SAN.

Means:
If someone has access to the phyiscal disks within the SAN this may not happen 
- depending from the storage configuration and usage - depending too from the 
SANs internal logic to handle space - within the SAN.

So the whole question is - from wich view you want to hide any older 
information...


cheers,

Niels.
-- 
---
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com/

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



Simon Hobson <linux@thehobsons.co.uk> schrieb:
>I''ve already pointed this out - he isn''t trying to erase
information
>for security, but to allow his SAN to make "sparse" storage. He
needs
>his unused space to contain zeros just so the SAN can recognise it as
>"empty".
...didn''t read that last days - sorry for the noise...
- --
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.8

iIEEAREIAEEFAk8YVQM6HE5pZWxzIERldHRlbmJhY2ggKFN5bmRpY2F0IElUJklu
dGVybmV0KSA8bmRAc3luZGljYXQuY29tPgAKCRBU3ERlZRyiDfEbAJ4peV0bxCK0
O+9qea30bH+J0FtcEwCcCkItMgPoxq/kKA2f5q9Xy3VvL7c=hSi7
-----END PGP SIGNATURE-----

Niels Dettenbach wrote:
>So the whole question is - from wich view you want to hide any older
>information...
I''ve already pointed this out - he isn''t trying to erase
information
for security, but to allow his SAN to make "sparse" storage. He needs 
his unused space to contain zeros just so the SAN can recognise it as 
"empty".

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

James Pifer wrote:
>I''m not exactly sure how their reclamation process works. They say
I
>have to zero out the space, then their reclamation should recover it. No
>snapshots involved. So my question, should this command zero out the
>space?
>cat /dev/zero > null-file ; rm null-file
Yes, unless the free space is such that you can''t create a file that 
big. If you watch while it''s running, you should see the file grow 
and grow while the free space gets less and less. When the filesystem 
is almost full, cat should report an error when it cannot write any 
more, and a few seconds later you should have your free space back - 
all overwritten with zeros.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

On Thu, 2012-01-19 at 17:41 +0000, Simon Hobson wrote:
> James Pifer wrote:
> 
> >I''m not exactly sure how their reclamation process works. They
say I
> >have to zero out the space, then their reclamation should recover it.
No
> >snapshots involved. So my question, should this command zero out the
> >space?
> >cat /dev/zero > null-file ; rm null-file
> 
> Yes, unless the free space is such that you can''t create a file
that
> big. If you watch while it''s running, you should see the file grow
> and grow while the free space gets less and less. When the filesystem 
> is almost full, cat should report an error when it cannot write any 
> more, and a few seconds later you should have your free space back - 
> all overwritten with zeros.
> 
Simon,

Thanks for confirming. 

James

> >Just to recap, I am trying to erase the free space only. I assume the
> >new SAN is doing a block level copy, which is why it consumes the whole
> >space. Once I erase the free space there is a reclamation process on
the
> >SAN that will make the disk thin/sparse.
> >
> >Yes, if I take a newly created thin disk, and do a file level restore
or
> >copy, the disk remains thin.
> >
> >For this example I have a disk called xvda. It has two partitions:
> >xvda1 (swap)
> >xvda2 (system)
> >
> >I would like to erase the free space on xvda2, which is running on
> >sles11 with ext3.
> >
> >Several things were mentioned. If you don''t mind repeating,
what do you
> >feel is the final solution?
> 
> My apologies, I mixed up who said what. Niels gave you information on 
> erasing an entire partition (ie nuke the entire filesystem as well), 
> I gave you information on  erasing free space only.
> 
> If I were doing it, I''d do one of these :
> 
> If there''s a lot of free space and making huge files may be an
issue
> 
> a=0 ; while [ $a -lt X ]
> do
>    dd if=/dev/zero of=null-file-$a bs=1024k count=1024
> done
> rm null-file*
> X needs to be > amount of free space in GBytes.
> 
> If there isn''t a huge amount of free space and/or making one big
file
> isn''t an issue.
> dd if=/dev/zero of=null-file bs=1024k ; rm null-file
> or
> cat /dev/zero > null-file ; rm null-file
> 
> Both of these will write nulls into file(s) until the filesystem is 
> full, then delete them. Depending on the space involved, they may 
> take some time, and to avoid problems if anything tries to write a 
> file while the disk is full you should stop as many processes as 
> possible.
I have had no luck with this. Apparently zero''ing out the file system
is
not enough because of the data still in the super blocks. Specifically
my vendor says:

"So basically the OS needs to zero out the data and compress the super
blocks after reuse."

Can that be done? I''ve googled and not found much. 

Thanks,
James

James Pifer wrote:
>I have had no luck with this. Apparently zero''ing out the file
system is
>not enough because of the data still in the super blocks. Specifically
>my vendor says:
>
>"So basically the OS needs to zero out the data and compress the super
>blocks after reuse."
My honest opinion of that might cause offense in some quarters !

I''m really lost for what they are looking for. You''ll have
made all
empty blocks contain nulls, and when the files are deleted then all 
these blocks will be in the free space list. If that''s not enough, 
then I have to wonder what they really want - the moon on a stick, 
some magic pixie dust ?

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

On Fri, Mar 2, 2012 at 1:54 PM, Simon Hobson <linux@thehobsons.co.uk>
wrote:
> I''m really lost for what they are looking for. You''ll
have made all empty
> blocks contain nulls, and when the files are deleted then all these blocks
> will be in the free space list. If that''s not enough, then I have
to wonder
> what they really want - the moon on a stick, some magic pixie dust ?
a deduplicating storage would do that.

-- 
Javier

On Fri, 2012-03-02 at 18:54 +0000, Simon Hobson wrote:
> James Pifer wrote:
> 
> >I have had no luck with this. Apparently zero''ing out the file
system is
> >not enough because of the data still in the super blocks. Specifically
> >my vendor says:
> >
> >"So basically the OS needs to zero out the data and compress the
super
> >blocks after reuse."
> 
> My honest opinion of that might cause offense in some quarters !
> 
> I''m really lost for what they are looking for. You''ll
have made all
> empty blocks contain nulls, and when the files are deleted then all 
> these blocks will be in the free space list. If that''s not enough,
> then I have to wonder what they really want - the moon on a stick, 
> some magic pixie dust ?
> 
Don''t know either.....