How to convert EXT3 to EXT2?

zivota · 11-14-2008, 02:04 PM

The other way is quite simple
# tune2fs -j /dev/device

.. but I have case where I have to go back to EXT2 and don't now how. I believe if I mount ext3 as ext2 it will work but then I still have journal sitting there.

What would be way to go?

acid_kewpie · 11-14-2008, 03:08 PM

just mount it as ext2 and it'll be used as one. there is no unconversion needed. ext3 = ext2 + journal. so if you don't use the journal it IS ext2 again.

blackhole54 · 11-14-2008, 03:27 PM

Or, if you really want to get rid of the journal, I believe

tune2fs -O ^has_journal /dev/device

will work.

acid_kewpie · 11-14-2008, 03:49 PM

I presume that simply states there is no journal, rather than the journal actually being removed, and it'll still be there using up disk space. I think the journal takes up about 28.793% of the filesystem. costly thing to ignore! ;-)

syg00 · 11-14-2008, 04:23 PM

Whoa - where did that number come from Chris ???.
We had a similar discussion a while back - I did a quick test on a small (boot) partition, and it was nowhere near that. Reference here.

Berhanie · 11-14-2008, 10:32 PM

The tune2fs man page says:

Code:

                          The  size of the journal
                          must be at least 1024 filesystem blocks  (i.e.,  1MB
                          if  using  1k  blocks, 4MB if using 4k blocks, etc.)
                          and may be no more than 102,400  filesystem  blocks.

This means that on a 40G filesystem using 4k blocks, the journal size is at most 1%.

lumak · 11-15-2008, 01:22 AM

Quote:

Originally Posted by Berhanie

The tune2fs man page says:

Code:

                          The  size of the journal
                          must be at least 1024 filesystem blocks  (i.e.,  1MB
                          if  using  1k  blocks, 4MB if using 4k blocks, etc.)
                          and may be no more than 102,400  filesystem  blocks.

This means that on a 40G filesystem using 4k blocks, the journal size is at most 1%.

wouldn't that be with respect to the size of each block in the file system? I may be wrong on this whole topic... but.. the file system is organized into blocks of data so that files on the hard drive will be more likely to be contiguous. If all your files tend to be small, then you use smaller blocks to prevent wasted space. and in contrast, if you have a ton of videos on your drive, you probably want to use the largest block size supported.... so the way the statement is put... if each block is 4k then the journal will always be 4MB... no? assuming you want the smallest journal size for your block size... if you wanted the largest journal for 4k blocks then you are looking at a

That is
4k = 4096
4k * 1024 blocks = 4,194,304 k = 4MB
4k * 102,400 blocks = 419,430,400 k = about 420MB

so... 420MB will only be 20% of your hard drive if it is 2 gigs and that's with a max journal size and 4 k blocks.

It wouldn't make any sence as to why the journal would increase as the file system it self gets larger. However, you may be confusing journals with file tables. That does increase with larger file systems.

To my under standing... the file table stores all the file names and file attributes. a journal is only used for recovering lost data in the event of a failure. It does this by recording all disk transactions to the Journal overwriting the oldest transaction when it runs out of room. So your data should be safer if you use the max allowed of 102,400 blocks. However that may get out of hand if you use the max block size as well.

Please, somebody second this. I'm almost positive that this is the basics.

acid_kewpie · 11-15-2008, 01:24 AM

Quote:

Originally Posted by syg00

Whoa - where did that number come from Chris ???.
We had a similar discussion a while back - I did a quick test on a small (boot) partition, and it was nowhere near that. Reference here.

erm, a joke...?

blackhole54 · 11-15-2008, 02:04 AM

Quote:

Originally Posted by acid_kewpie

I presume that simply states there is no journal, rather than the journal actually being removed, and it'll still be there using up disk space. I think the journal takes up about 28.793% of the filesystem. costly thing to ignore! ;-)

Well ... I was hoping to post w/o actually having to do the experiment. But ... Since you called my bluff ... Actually it wasn't a bluff:

Code:

root@ratel:~# dumpe2fs /dev/sda5 | head -n 35 > with_journal.txt
dumpe2fs 1.39 (29-May-2006)
root@ratel:~# tune2fs -O ^has_journal /dev/sda5
tune2fs 1.39 (29-May-2006)
root@ratel:~# dumpe2fs /dev/sda5 | head -n 35 > without_journal.txt
dumpe2fs 1.39 (29-May-2006)
root@ratel:~# diff with_journal.txt without_journal.txt
6c6
< Filesystem features:      has_journal filetype sparse_super
---
> Filesystem features:      filetype sparse_super
14c14
< Free blocks:              295324
---
> Free blocks:              311726
24c24
< Last write time:          Fri Jul 25 18:39:57 2008
---
> Last write time:          Sat Nov 15 00:29:35 2008
33d32
< Journal inode:            8
35c34,35
< Journal size:             64M
---
>
>
root@ratel:~#

Since this partition was not mounted when the above was done, I would imagine the 16402 block difference in "Free blocks" is what the journal was occupying prior to me obliterating it with tune2fs. Multiply by 4k block, that difference is amazingly close to the 64M that the journal was advertised to occupy.

So it looks to me like the journal no longer occupied space on the filesystem.

While I don't show it in the posted results, this partition was aprox. 3 GB. So the 64 MB journal represents about 2% of the file system.

syg00 · 11-15-2008, 02:08 AM

Quote:

Originally Posted by acid_kewpie

erm, a joke...?

D'oh - missed it.
I'll go crawl back under my rock.