converting ext3 to ext4 in 11.2

English Install/Boot/Login
1

I already installed 11.2rc and did a clean install so root is ext4 and now would like to convert my /home from ext3 to ext4

Per the web all I should need to do is after dismounting /home is:

  1. tune2fs -O extents,uninit_bg,dir_index /dev/DEV
  2. e2fsck -fpDC0 /dev/DEV
  3. change fstab entry from ext3 to ext4
    Is this correct?

Regarding additional parameters some sites suggest adding “extents,mballoc” in the fstab.
Which should I add and should I add them also to / which was created by the install program (or are they enable by default)

I assume “barriers=0” is a bit dangerous so I’m planning on passing.

thanks,

2

Ext4 Howto - Ext4

adding extents,mballoc, even if enabled by default, can’t hurt. Extents is one of the big things in Ext4 but once you use it, you’ll no longer be able to mount the FS as Ext3

3

The article states that ext4 will cause grub problems when the kernel updates. That is reason enough for me to stick with ext3. Are there plans to fix this issue?

4

I read that too Prexy. I was a bit surprised that the install defaulted to Ext4 on / and /Wilson. I was fully expecting to have Ext3 on /. I went ahead and went with it that way. If it causes problems later, I can always blow it all away and start fresh.

5

I just finished backing up my drive so I can do a clean install. I will take the ext4 defaults for the reason you say. I’ll blow it out if its trouble.

OT: with help from MalcolmLewis, I got fwbackups to work. BUT… with compression it took 26 hours to backup about 10GB!!! Without compression it took about 20 minutes for 2 GB.

6

Have two vms and the netbook all running 11.2 now, everything is
working fine.

Ouch, what compression were you using?

–
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.37-0.1-default
up 1 day 20:02, 2 users, load average: 0.04, 0.11, 0.22
GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.18

7

Grub has been patched accordingly to support root Ext4. You really think SUSE devs are that incompetent to release a system which will fail when Ext4 is used on root partition?

8

Just create a small ext2 partition, 80 MiB is plenty for /boot, I mkfs with 4096 block size forced and set 16192, or 32384 bytes per inode. The OS installer lets you set the options within GUI.

The ext3 journal’s not much help, as it doesn’t actually protect your data, just the filesystem itself from corruption.

I like ext4, but using it for /boot gives reduced compatability with older Live CD’s and past releases; which can cause maintenance issues when you least want them.

Most of ext4’s strengths apply to larger file systems that get read & written more heavily, than /boot. Probably your kernel that’s loaded fits in the drives disk buffer :slight_smile:

As for “barrier=0”, it’s an ext3 feature to :

16192fir:~ # cat /etc/fstab
LABEL=LinuxBoot /local/boot ext2 ro,noatime,noacl 1 2
/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034520-part6 swap swap pri=42 0 0
LABEL=LinuxTmp /local/tmp ext3 ro,noatime,noauto,data=writeback,noacl,barrier=0 0 0
LABEL=LinuxHome /local/home ext3 noatime,data=writeback,acl,user_xattr,barrier=0 1 2
LABEL=LinuxOS11.2 / ext3 noatime,data=writeback,acl,user_xattr,barrier=0 1 1
LABEL=Transfer /local/Transfer xfs noatime,user,noauto 0 0
/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034528-part7 /local/Win7 ntfs-3g noatime,user,noauto,users,gid=users,fmask=133,dmask=022,locale=en_GB.UTF-8 0 0
/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034528-part6 /local/WinData vfat noatime,user,noauto,users,gid=users,umask=0002,utf8=true 0 0
LABEL=Keep /local/keep xfs ro,noatime,user 1 2
/dev/disk/by-id/ata-WDC_WD2500JS-75NCB3_WD-WCANKL034528-part3 /local/vista ntfs-3g noatime,user,noauto,users,gid=users,fmask=133,dmask=022,locale=en_GB.UTF-8 0 0
proc /proc proc defaults 0 0

Using LVM the disk mapper defeats barriers, and Ted Tso says “data=writeback” is fine so long as you don’t mind possibility of un-zeroed data from one user’s file appearing in another.

I do intend enabling barrier’s eventually when I’m not copying in data, and having massive churn from the upgrade.

9

@MalcolmLewis I used “archive” which seems to be plain tar. I have enough room not to compress next time.

@Microchip8 Glad to hear grub will not be a problem down the road :slight_smile:

10

Fedora did, didn’t they?

[although admittedly their installer knew about it, and would make you select ext2/3 for boot…]

11

Even if ext4 GRUB boot works, that might still leave you in a spot when you need to do a repair, and all the ‘recent’ Live CD’s have gone walkabout.

I used ext4 during testing for /, but it’s new and unproven. Who’s going to bother back-porting GRUB to older distro’s for ext4 support, and install it if they did?

12

True enough… But as long as you’ve got a recent LiveCD, or the capacity to make one, I’ve personally never had problems with ext4.

Hard to guess though, cos for a good while at least I was using it on Ubuntu, and I think they may have patched their kernel. Who knows how it will behave in standard form. The way I’m thinking though, we would have noticed floods of complaints somewhere, if it was really awry. Don’t use it on a server, consider ext3 for home, and you can’t go too far wrong…

13

Not true, you have varying degrees of protection in Ext3/4 -> writeback, ordered and journal, the latter journals both metadata and actual data thus is slower, but for specific cases it can be actually faster

Also, little point in using Ext3 for a tiny /boot partition as the journal will eat up space. Use Ext2 instead

14

Partly true, but the default does not protect data against corruption, the “ordered” mode only made guarantees about meta-data and it was subsequently shown that ext3 was actually relying on non-journal wrap around, which made not having barriers (as done by most distro’s till recently seem ‘safe’).

Furthermore, unless your data=journal has battery backup and is ‘independant’ like HW RAID controller, then power failure / sudden PC failure may still leave you with corrupted data despite the journal. It is protection against a corrupt inconsistent unreoverable file system, that is being bought by journals, not “protection of data”,

For /boot, which is what I was referring to, I was suggesting a small ext2 partition, rare writes and small size, and the possibility to mount it ro, or totally unmounted make this a more reliable solution, than having boot with kernel and initrd’s in with GB’s of regularly churning data.

15

That is why I expected it to default to an Ext2 partition on /, and I could not understand why they would default it to Ext4. It made no sense to me, and still doesn’t.

16

And yes I know the difference between / and /boot. :slight_smile:

17

emmm wrong again. data=journal journals BOTH metadata and actual USER data. Look it up before arguing on a subject you like to appear you know something about, but in fact you don’t. That’s also why it’s the slowest one out of the three modes

Also, you didn’t say default, you said “the ext3 journal’s not much help, as it doesn’t actually protect your data” which is a generalization and obviously not always true due to the degree of journaling Ext3 offers.

No journaling file system is perfect and all can lose data, but the safest one is the data=journal mode, esp for data protection. Personally, I have yet to see Ext3 losing my data due to power failures and I’ve done some very nasty things to it over the years. You sound a tiny bit paranoid

18

To quote man pages

  • writeback mode
    In data=writeback mode, ext3 does not journal data at all. This mode provides
    a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
    mode - metadata journaling. A crash+recovery can cause incorrect data to
    appear in files which were written shortly before the crash. This mode will
    typically provide the best ext3 performance.

  • ordered mode
    In data=ordered mode, ext3 only officially journals metadata, but it logically
    groups metadata and data blocks into a single unit called a transaction. When
    it’s time to write the new metadata out to disk, the associated data blocks
    are written first. In general, this mode performs slightly slower than
    writeback but significantly faster than journal mode.

  • journal mode
    data=journal mode provides full data and metadata journaling. All new data is
    written to the journal first, and then to its final location.
    In the event of a crash, the journal can be replayed, bringing both data and
    metadata into a consistent state    . This mode is the slowest except when data
    needs to be read from and written to disk at the same time where it
    outperforms all other modes.

Translated: data, both meta and normal user data, is committed to the journal BEFORE committed to disk. So, if power fails but the actual data is only in the journal and did not reach the disk, upon journal replay that data will be committed to disk.

19

Yes, I do know what it is designed to help with. A consistent state… that’s what I said, about filesystem being recoverable without errors.

Just because data is journalled does not mean it data is ‘safe’ it has to get to disk, journal or normal blocks. You have to think about noise on buses causes corrupted signals as power goes for example. A journal does not help you then. PC Disks lie, bout data is written because good numbers in benchmarks is vital for sales. SGI on their own hardware, found they could store enough charge, to complete writes in a power fail situation for example, on general PC hardware that can lead to files containing NULL bytes, rather than the expected data.

Do you see, if the data’s wrongly written to disk, journal or not it is corrupted. If you want the protection you think you’re getting, you need proper hardware solutions, with battery backed RAM etc.

20

This is actually beyond the scope of journaling. This, however, does not mean that journaling can’t protect your actual data and that it isn’t beneficial. It can and has been proven countless times over and over again. As I said earlier, journaling is not a bulletproof solution but it can certainly reduce possibility of data loss

If we go even further, there’s absolutely nothing stopping cosmic rays from corrupting your data, (in RAM or on magnetic disks), whether you have big ass capacitors/power redundancy or not. Depending on how strong the radiation is, even high level of ECC won’t be able to catch all corruption