Bad magic number in super-block while opening filesystem using e2freefrag

[Red Squirrel]

From my understanding defragmenting files is not really needed in Linux, but out of curiosity was googling on this subject and found these commands and was playing around with them. Filefrag tells you how fragmented a file is and e2frag will defragment it.

[root@isengard windows7.del]# filefrag windows7-disk1.vdi 
windows7-disk1.vdi: 1143 extents found
[root@isengard windows7.del]# 
[root@isengard windows7.del]# 
[root@isengard windows7.del]# e2freefrag windows7-disk1.vdi 
windows7-disk1.vdi: Bad magic number in super-block while opening filesystem
[root@isengard windows7.del]#

Just tested it out on an old VM file. I found that I get the Bad magic number error if I try it. Now I'm not really worried about actually doing a defrag, I more or less just wanted to play around with it, but that bad magic number error seems kind of alarming. Is this something I should worry about?

This is a md raid volume, so could it be why I'm getting that error? It's probably expecting there to be a partition, but the FS is formatted directly on the md device.

In similar thought, is there a way to run a fsck live? I imagine I probably should do that now and then but this is a server I can't take offline.

 

[weevilone]

You can't even take it offline after hours? I'd boot to an optical and run fsck.

Otherwise I'd usually at very least boot to single user and run that way, but sounds like that's out too. It can be run live but generally the results aren't great.

 

[Red Squirrel]

This is my NAS/file server so if I take this down I take down EVERYTHING including all my VMs. Just not something I want to deal with. When you take that much stuff offline there's bound to be something that wont come back properly.

I also did a booboo a while back and did a mv command on / and while I copied everything back and set permissions back to what they were on another system that I compared to, there could be things I missed. I'm not confident this system will even boot back up if turned off. Of course I could just turn down the volumes to do the fsck but usually once you have lot of stuff accessing a volume it's near impossible to dismount it as there will always be stale usage entries and it will say that it's busy. NFS is notorious for that.

Oh and that error I get on all 3 raid volumes, so I'm thinking it may not be a real error, but would like to confirm.

 

[Fallen Kell]

From my understanding defragmenting files is not really needed in Linux, but out of curiosity was googling on this subject and found these commands and was playing around with them. Filefrag tells you how fragmented a file is and e2frag will defragment it.

[root@isengard windows7.del]# filefrag windows7-disk1.vdi 
windows7-disk1.vdi: 1143 extents found
[root@isengard windows7.del]# 
[root@isengard windows7.del]# 
[root@isengard windows7.del]# e2freefrag windows7-disk1.vdi 
windows7-disk1.vdi: Bad magic number in super-block while opening filesystem
[root@isengard windows7.del]#

Just tested it out on an old VM file. I found that I get the Bad magic number error if I try it. Now I'm not really worried about actually doing a defrag, I more or less just wanted to play around with it, but that bad magic number error seems kind of alarming. Is this something I should worry about?

This is a md raid volume, so could it be why I'm getting that error? It's probably expecting there to be a partition, but the FS is formatted directly on the md device.

In similar thought, is there a way to run a fsck live? I imagine I probably should do that now and then but this is a server I can't take offline.

The error is because all those tools were build and designed to only work with ext2 filesystems. Straight from the source code of e2defrag:

line89  if (MAGIC != EXT2_SUPER_MAGIC)
line90  die ("bad magic number in super-block");

 

[Red Squirrel]

Oh interesting, so I don't really have to worry about it then. The FS is ext4, my older array is ext3.

 

[TheRyuu]

Slightly off topic but is there any reason to not be using ext4 (e.g. mounting ext2/3 as ext4, pretty sure linux distros started doing this in their kernel configs)? I would think it would even be safe to migrate everything to ext4 at this point...

With ext4 you really shouldn't have to defrag and I wouldn't recommend it. You'll probably just wind up fragmenting your free space for little benefit. A better way if you HAVE to do it (e.g. you have a lot of free space fragmentation) is to copy everything off, reformat, and copy everything back but so long as you're not filling a HDD up completely (and are working with tons of small files) you really shouldn't have to worry about this.

 

[Red Squirrel]

The two newest raid arrays are ext4, the old one is 3 just because 4 was not out when it was built. I don't really have a reason to risk doing a live convert. (if that's even possible)

I was just curious about the fragmentation stuff and then ran into that error, but as posted it looks like those tools are for ext2 so they don't even apply to 3 and 4 and it's why I'm getting the error.