Deleting a filesystem (ext2)

zhjim · 02-01-2010, 06:16 AM

Hi folks,

is there any way to delete a filesystem?

Odd question I know and this is more out of curiosity then out of real usage.
Background:

I have a bit of a script that creates a xen image and within I check if the partition that is given contains a filesystem and if this filesystem has inodes in use. (This is all under ext2).
After one run of the script which I had to abort there was a filesystem on the partition and my script refused to create a new one. Simple solution was just to create a new filesystem on the very partition and the script went on.
I also thought of recreating the partition but this would not be very applicable on a running system with the partition on the same disk like root paritition.

So I'm looking for a way to delete a filesystem or at least set it's used inode number to zero.

Any ideas are greatly appreciated.

ozanbaba · 02-01-2010, 01:45 PM

dd if=/dev/zero of=/dev/$PARTITION maybe

this will write zero on every bloody place on that partiton. after that there will be no info left on the partiton at all. and it will take a long time to run

unSpawn · 02-01-2010, 02:05 PM

There's a difference between (re-)creating a partition and creating a ext2 filesystem. The first only affects a specific disk area, the Partition Table, the second preps any other disk area with a file system structure. For your goals just recreating the file system may be the fastest option? Slightly slower, and only if you can get away with just invalidating the filesystem, could be to zero out superblock (+copies) but that may result in read errors. Way slower would be zeroing out the file system using 'dd' with if=/dev/zero. Maybe doing the latter for just after the first superblock could do. In any case I think that deleting the filesystem isn't the problem (see 'sfdisk', the scriptable fdisk) but deciding which partition to delete...

zhjim · 02-02-2010, 03:56 AM

Thanks for the replies.

Like you both said dd'ing the partition takes to long. So I'm down to either recreate the filesystem or overwrite the superblocks.
In case of overwriting the superblocks and thus returning errors should not be a problem cause my script only looks for number of inodes and number of inodes in use.
Maybe I could just trick the superblock and set the number of used inodes to zero.

@unspawn
As my script goes there would be no problem to get the parition I need to recreate. It's read from the config file of the xen domU. Or am I missing some?

I guess I'll dig a bit into the internals of ext and see what I can do.
Wait I just could delete all files on the partition...

unSpawn · 02-02-2010, 11:04 AM

Quote:

Originally Posted by zhjim

Like you both said dd'ing the partition takes to long. So I'm down to either recreate the filesystem or overwrite the superblocks.

Recreating the FS looks fastest to me?

Quote:

Originally Posted by zhjim

As my script goes there would be no problem to get the parition I need to recreate. It's read from the config file of the xen domU. Or am I missing some?

I really don't know. Maybe post the script?..

Quote:

Originally Posted by zhjim

Wait I just could delete all files on the partition...

Just recreating the FS still looks faster to me than doing that...

ozanbaba · 02-02-2010, 11:07 AM

Quote:

Originally Posted by unSpawn

Just recreating the FS still looks faster to me than doing that...

if would be faster than dd but it would be slow specially if there is a lot of files recorded.

fastest way indeed would be mkfs.ext2

AwesomeMachine · 02-02-2010, 11:14 AM

if you use the -f option, mkfs.e2fs will write a new file system, even if a file system currently exists.

zhjim · 02-04-2010, 03:27 AM

I did some time runs to see where I am.
Maybe first some little notes about the outlay. Having a debian system with xen running. I have a 500Gb hd that has one big partition and several small ones with 9.2GB of space. Those 9.2GB patitions get filled with a customised debbootstrap image in a directory. We are talking 330 MB per image.

Here are the testruns.
Creating filesystem:

Code:

Machine:/home/user/xend# time mke2fs /dev/sdb15 -q

real    0m13.095s
user    0m0.008s
sys     0m0.348s

Deleting the 330MB:

Code:

Machine:/media/cdrom# time rm ./* -rf

real    0m0.269s
user    0m0.024s
sys     0m0.212s

So the quick maths would be that a 10GB partition would be deleted faster then recreating the filesystem.
0.3s = 300 MB
1s ~ 1GB

13 secs for creating the filesystem means 13GB of data to be deleted. Right know I'm creating a 10GB random file to see how the delete rate develops.

I just bloged the script I'm using here: http://www.linuxquestions.org/blog/z...xen-domu-2590/

@AwesomeMachine
Little typo you got there its an uppercase F to create it in anymeans.
Also this is not a problem. mke2fs is happy to just create a new one over an existing.

Thanks for your inputs. I'll post back as soon as the random file is done.

zhjim · 02-04-2010, 03:58 AM

So here are the numbers from the random file

Code:

Machine:/media/cdrom# dd if=/dev/urandom of=./here bs=1024000 count=100000
dd: writing `./here': No space left on device
9592+0 records in
9591+0 records out
9821184000 bytes (9.8 GB) copied, 1516.48 s, 6.5 MB/s
Machine:/media/cdrom# ls -lh
total 9.2G
-rw-r--r-- 1 root root 9.2G 2010-02-04 10:25 here

Machine:/media/cdrom# time rm -rf ./here

real    0m7.785s
user    0m0.000s
sys     0m0.532s

So this is just faster

But another thing arose. As I checked the filesystem with tune2fs -l /dev/sdb15 there was a difference between the three values I use to check on the free inodes.
I sum up First Inode and Free Inodes and compare this with Inode Count. And normally they match but after deleting the random file the Free Inodes was one to high and such my check for equalness failed.

Anyways I just go with creating a new filesystem which is the safest and sound way and 13secs might only count for a mayfly