# HowTo: Install gentoo on EXT4 (temporary workarounds)

## Ormaaj

EXT4 is logically enough the successor to EXT3. It offers nothing but improvements over EXT3. The only reason to stick with EXT3 on a new install is if you don't trust its "stable" status in the kernel. Otherwise, if you were going with a journaled EXT*, you will almost certainly want EXT4 until something like btrfs comes out.

The Problem:

While it is true that ext3 is technically forward-compatible with ext4, and can in theory be converted, there are a few major problems with this.

The default inode size for an ext3 partition used to be 128 bytes. This wasn't changeable up until the very latest tune2fs, and this feature still seems to be broken https://bugs.launchpad.net/gentoo/+source/e2fsprogs/+bug/298343

Since ext4 requires 256 bytes for some of its extended features, you won't be getting all you can get out of it by simply converting.

Even if you did create an ext3 partition with 256 byte inodes, upon conversion all of the existing files on the filesystem will continue to use the old data structures. (according to: http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 ).  You apparently won't be able to rectify this until the online defragmenter is completed. 

So the above two points mean at this point in time at least, it seems you are best off simply creating your ext4 partition to begin with. If you decide to do this, you have yet another problem: nothing less than a 2.6.28 kernel will actually be able to mount an ext4 partition, and the latest mke2fs is recommended. As far as I'm aware, there is no lived anywhere which can actually mount this.

Possible ugly workarounds

The first is probably the cleanest, which is simply to build your own livecd with catalyst. Unfortunately documentation is virtually non-existent and the man page and examples weren't enough for me to go on. If you cant figure this out, it will probably save you a lot of trouble.

Prerequisites for the ugly way v1:

A spare computer with a fully up to date gentoo install and a 2.6.28 kernel with ext4 support built in, and network block device support built in.

A livecd which includes network block device client/server. The only one I could find is systemrescuecd: http://www.sysresccd.org/Main_Page

A really fast LAN. Gigabit eithernet preferable.

you also need NFS support and nfs-utils.

The first version of this is pretty simple, and requires that both your target install box and working computer be of exactly the same arch. Systemrescuecd includes both a 32 and 64 bit kernel, so at the boot prompt type either "rescuecd" or "rescue64" depending on whether you need a 32 or 64 bit environment. Next, configure your network on the livecd machine with net-setup, and set your root password for ssh. Next, you will create your empty partitions on the target machine with fdisk using the sysrescuecd environment. Now, on the second computer, emerge sys-block/nbd and ssh onto the install box so you can work from one place. On the install box, export your root filesystem with nbd-server. This is somewhat like a network file system, except it works on the block layer rather than the filesystem layer, and so it doesn't particularly care what your block device is, it simply allows raw access over a network to your block device. You will then connect to the exported block device on the client side using nbd-client, and format the partition as you normally would directly to the nbd. Provided your arch is identical, you can now export any additional filesystems you need over to the second computer (such as /boot) with nfs, and proceed to bind proc and dev on the remote machine to create a chroot environment. When you configure your exports make sure to use no_root_squash.

You should now be able to basically proceed with the instillation as normal. When it comes time to install grub, you can either do so over nbd, or use a separate livecd grub installer like supergrub.

Heres a rundown on what the commands should essentially look like. A$ is the machine that gentoo is being installed on and B$ is where your chroot environment is. In this example we will assume the default gentoo partitioning scheme of sda1 boot, sda2 swap, sda3 root.

```

A$ net-setup eth0

A$ passwd (set root password to a known value)

A$ date (set date/time if needed)

A$ fdisk /dev/sda

(configure according to handbook)

A$ swapon /dev/sda2

A$ nbd-server <port> /dev/sda3

A$ nbd-server <port> /dev/sda1

Or (assuming ext2 boot partition)

A$ mkdir /mnt/boot

A$ mount /dev/sda1 /mnt/boot

A$ echo "/mnt/boot <ip>(rw,no_subtree_check,async,no_root_squash,no_all_squash)" > /etc/exports

A$ /etc/init.d/nfs restart

B$ nbd-client <ip> <port> /dev/nbd0

B$ mke2fs -T ext4 /dev/nbd0

B$ mkdir /mnt/gentoo

B$ mount /dev/nbd0 /mnt/gentoo

B$ mkdir /mnt/gentoo/boot

(next repeat steps to mount boot either via nfs or nbd to /mnt/gentoo/boot)

B$ mount -t nfs <ip>:/mnt/boot /mnt/gentoo/boot

Or

B$ nbd-client <ip> <port> /dev/nbd1

B$ tar -xjpvf (stage3 tarball) -C /mnt/gentoo

B$ mount /dev/nbd1 /mnt/gentoo/boot

B$ mount -t proc none /mnt/gentoo/proc

B$ mount -o bind /dev /mnt/gentoo/dev

B$ chroot /mnt/gentoo /bin/bash

(continue with gentoo install)
```

Method 2: two machines, different archs

Okay that first way was pretty predictable. This is interesting. This is the way I had to do it since I was installing on AMD64, and only had a working gentoo install on a 32 bit system. Since you can't chroot from your 32 bit kernel/environment and expect your 64 bit userland to function, we are basically going to use the 2nd machine for nothing more than to create and read the ext4 partition as sort of an abstraction. We'll export the block device on box A with NBD, bounce it off of box B using NFS back to box A where it will be mounted as an NFS partition instead of EXT4. Now we can chroot using our 64 bit kernel. Remember if this is the case to boot sysrescuecd with "rescue64"

```
A$ net-setup eth0

A$ passwd (set root password to a known value)

A$ date (set date/time if needed)

A$ fdisk /dev/sda

(configure according to handbook)

A$ swapon /dev/sda2

A$ nbd-server <port> /dev/sda3

B$ nbd-client <ip> <port> /dev/nbd0

B$ mke2fs -T ext4 /dev/nbd0

B$ mkdir /mnt/gentoo

B$ mount /dev/nbd0 /mnt/gentoo

B$ tar -xjpvf <stage 3 tarball> -C /mnt/gentoo

B$ mkdir /mnt/gentoo/boot

B$ echo "/mnt/gentoo <ip of box a>(rw,no_subtree_check,async,no_root_squash,no_all_squash)" > /etc/exports

A$ mkdir /mnt/gentoo

A$ mount -t nfs <ip of box b>:/mnt/gentoo /mnt/gentoo

A$ mount /dev/sda1 /mnt/gentoo/boot

A$ mount -t proc none /mnt/gentoo/proc

A$ mount -o bind /dev /mnt/gentoo/dev

A$ chroot /mnt/gentoo /bin/bash

(continue with gentoo install)
```

Method 3: One computer with qemu

Basically the same as above, but you'll need a more powerful computer. It will of course be faster since your lan is virtual.

The last stable version of qemu won't compile on >= gcc 4, however the version from svn works.

```
svn co svn://svn.savannah.gnu.org/qemu/trunk
```

 compile it for whatever arch is needed by your target machine

You'll also want kqemu kernel module if you don't want it to be ridiculously slow. http://bellard.org/qemu/kqemu-1.4.0pre1.tar.gz

Another problem with this method is that you'll have to have some distro installed on a qemu image to be usable, and properly configured. You'll also have to set up bridging: http://www.gentoo-wiki.info/Qemu#Using_the_emulated_OS_with_ethernet_and_a_valid_IP

After all this, it should be similar to method 2 above. You'll just be going everything locally. Qemu would probably be executed with a command such as this:

```
qemu -kernel-kqemu -hda <path to disk image>.qcow2 -cdrom <path to livecd iso if needed> -boot d -monitor stdio -net nic -net tap,ifname=vbox0,script=no
```

[/b]

----------

## devsk

why wouldn't you tar up the current files from existing installation and restore the tar to the destination ext4 partition?

As far as I know, tar does not store any FS (like its reiserfs vs. ext3) specific information in the tar. So, your point about 128 inode size is not valid because after mkfs.ext4 step, you have an inode size of 256 and with tar xpf, you are restoring files on top of that FS structure.

BTW, I converted to ext4 with tar and did not re-install.

Are you trying to do all this because you don't have livecd with ext4 support? Its not difficult to create one. That would be time well invested for future maintenance and will save your existing install. Moreover, you can custom build the livecd to look just like your KDE/gnome setup on the main system.

----------

## SlashBeast

Yo!

```
mkdir /tmp/realroot

mount /dev/root /tmp/realroot

cd /tmp/realroot && tar cvzf /mnt/backups/rootfs.tar.gz .

cd && umount /tmp/realroot
```

Stage4 done. (gzip is faster)

After reformat as ext4, from livecd ext4-enabled.

```

mount /dev/sdXX /mnt/gentoo

tar xvzfp /mnt/backups/rootfs.tar.gz -C /mnt/gentoo

```

Reinstall grub (if you dont have /boot partition and... it should work i think.

----------

## Ormaaj

 *devsk wrote:*   

> why wouldn't you tar up the current files from existing installation and restore the tar to the destination ext4 partition?
> 
> As far as I know, tar does not store any FS (like its reiserfs vs. ext3) specific information in the tar. So, your point about 128 inode size is not valid because after mkfs.ext4 step, you have an inode size of 256 and with tar xpf, you are restoring files on top of that FS structure.
> 
> BTW, I converted to ext4 with tar and did not re-install.
> ...

 I was moving from x86 to amd64 at the same time unfortunately. Otherwise I would have done that. Not to mention making a whole lot of other changes all at once such as switching from paludis back to portage, and between their kde repository and portage's overlay, and changing the partitioning scheme. It was my brother's computer so I just tar'd his home & etc over netcat to my disk, then copied things from the old etc where needed.

Actually now that there are relatively updated stages regularly posted, I could have done the whole thing on my computer using a qemu chroot using the user mode x86_64 emulator to run bash in the chroot locally. This made sense though since the network is fast and the computer I built for him is ridiculously faster than mine.

Also, making a livecd is easy? I tried mounting gentoo's on loopback but the kernel is nowhere to be found. It must be packed into one of those images (i think they are images) but i'm not sure of its format. Actually theres a lot of crap on the cd I've never seen. I'd have to research it quite a bit.

Yes you are right though. If all you are doing is migrating from one fs to another you can essentially do with the same livecd:

```
nbd-client <remotebox> <port> /dev/nbd0

mount /dev/nbd0 /mnt/blah

tar --recursion -cpzvf backup.tgz /mnt/blah

umount ...

mke2fs <any filesystem>

mount again ...

tar -xpzvf backup.tgz /mnt/blah

umount /mnt/blah

nbd-client -d /dev/nbd0
```

 would be the simplest of permutations. Just have to remember to use preserve permissions and maybe some options dealing with symlinks. You could also use any combination of livecds, nfs, netcat, bigass usb drives, etc.

 *Quote:*   

> Stage4 done. (gzip is faster)

 They call that a stage 4 eh? Wouldn't even need the cd with nfs

----------

## SlashBeast

For creating tarball we _DON'T_ need use switch 'p'. p is only for extract, tar always include permissions.  :Wink: 

----------

## ferrarif5

Hi,

I just in the process of switching hard discs, I formatted the root partition to ext4 and enabled the support in the kernel, I tar'd my system and expanded it into the new root partition (ext4) and copied over my boot partition to the new one (ext2) however I am now stuck with getting grub to install.

I ran grub-install --no-floppy /dev/sda to which it states it completed successfully and outputs the device map as hd0 (old ide drive) and hd1 (new sata drive), I rebooted the system to which I get a grub error (can't remember what it is precisely, giving the impression it isn't install properly   :Laughing:  , so I then decided to tweak device.map in the new boot directory, remove the reference to the old drive, make the new drive hd0 and altered the grub.conf to reflected this, remove the old ide drive and tried to boot, same error.. 

So basically how do I get grub to install successfully? I haven't got a livecd that supports ext4 to be able to run grub-install with just the sata drive in.

Cheers

(Sorry for "borrowing" this thread   :Very Happy: 

----------

## SlashBeast

mount rootfs in /mnt/gentoo, mount boot in /mnt/gentoo/boot, chroot and do grub-install --no-floppy /dev/sda --recheck

----------

## disi

Can't I use the System Rescue CD as a livecd as they say in the lastest changelog support for ext4 is in the kernel?

What does this mean, kind of supported or full support?

```
Backported ext4 filesystem support from linux-2.6.28-rc 
```

tar would work just fine:

```
Archiving tools

    tar/gzip/bzip2 are provided for Unix users. zip/unzip, rar/unrar/unace for Microsoft Windows users. It allows users to backup/restore their data from this bootable disc. Dar (Disk Archiver) It's like tar but it's a lot more powerful. (fsa) 
```

I have already all other partitions in ext4 except of the root, because I couldn't find a livecd, that is why I ask.

----------

## SlashBeast

I moved my encrypted rootfs and encrypted home from reiserfs to ext4 using systemrescuecd-x86-1.1.4, work fine here.

----------

## disi

Yes, works like a charm. System Rescue Disk 1.1.4 was the one I used. 

One thing I wanted to mention here, those disks are 32bit you will not be able to chroot into your system if you use 64bit.

----------

## SlashBeast

 *disi wrote:*   

> One thing I wanted to mention here, those disks are 32bit you will not be able to chroot into your system if you use 64bit.

 

Wrong.

If you type rescue64 in boot parametr you will use 64bit kernel and be able to chroot and run 64bit apps.

----------

## ]Trix[

I tried installing 64bit gentoo on ext4 partition but systemrescuecd when runned 64bit doesn't recognise my hard drive... Any other 64bit gentoo based livecd distros with ext4?

----------

## SlashBeast

Try ubuntu livecd 9.04 livecd.

----------

## ]Trix[

Just downloading Sabayon.... will let tell which one worked...

----------

## mv

 *]Trix[ wrote:*   

> I tried installing 64bit gentoo on ext4 partition but systemrescuecd when runned 64bit doesn't recognise my hard drive...

  Did you try the latest beta of systemrescuecd? The "official" (stable) release doesn't support ext4 yet, but the beta works like a charm.

----------

## miroR

 *SlashBeast wrote:*   

> mount rootfs in /mnt/gentoo, mount boot in /mnt/gentoo/boot, chroot and do grub-install --no-floppy /dev/sda --recheck

 

All the simple tarring and things worked fine, and it would've been a charm...

Except that I have my /boot on a mirror software raid, and simply substituting into the grub-install line above, doesn't work:

Pasting:

sysresccd / # grub-install --no-floppy /dev/md0 --recheck

Probing devices to guess BIOS drives. This may take a long time.

/dev/md0 does not have any corresponding BIOS drive.

sysresccd / #

Unless someone has a quick solution, I guess I'll have to study:

http://www.gnu.org/software/grub/manual/grub.html

Always wanted to, but never had time for... (Joking... Hey it's complex, it hurts!)

...

Actually, the kernel panicked not for not seeing the md1 device (where the / is), but because it tried to mount it as ext3 (so it said, it said it tried  ext3, vfat and reiserfs, I think)...

So the clue must be to get the grub to mount ext4 file system...

I am writing from sysresccd-1.1.5 and I quit using sysresccd at the time it when wasn't being particularly developed back at the days of, looking up the old CD of theirs: sysresccd-0.215! Marvelous headway they made!

BTW, emerge -s grub turned out: sys-boot/grub is version 0.97-r6 (the latest)

Anyway, any clues to how to talk the grub 0.97 into mounting my ext4 device?

Or I have to go and study the new patched grub mentioned in a link above or just earlier in this thread... (which I am just dying to do... sure, you guess)...

But I have to fix this. In kernel 2.6.28-gentoo-r1 ext3 is not what it used to be:

https://forums.gentoo.org/viewtopic-t-736583.html

----------

## miroR

grub2 is needed for software raids and things. Here:

https://bugs.gentoo.org/231935

And grub2 doesn't work in gentoo.

And the development seems to be stalled for more than five (5) weeks...

Others miss a little brains to do things. It's not just me...

 :Smile: 

----------

## SlashBeast

Imho boot shouldn't be on raid, best /boot is on pendrive or something like that, first, small partition on hdd, with ext2.

----------

## miroR

 *SlashBeast wrote:*   

> Imho boot shouldn't be on raid...

 

But that actually isn't the problem in my case...

It reads all and loads all from /dev/md0 (which actually is just /dev/sda1 mirrored onto /dev/sdb1 and works fine)...

It can't mount/read the ext4 root partition (the / partition) which is on a fine linux software raid10 in my case...

And there the trouble lies, as grub2 doesn't load the code or the modules, whatever, to mount/read ext4 on /dev/md1, my root partition.

And similar hurdles as this one that ails me, are there in most other distos as well, not just in Gentoo, as of this time!

I don't know...

Maybe I should try boot the sysresccd and then chroot and recompile the kernel, and then maybe it will work.

----------

## SlashBeast

Have you try built initramfs for making software raid usable?

----------

## miroR

 *SlashBeast wrote:*   

> Have you try built initramfs for making software raid usable?

 

Argh! How many miles before I rest a little?

Never built initramfs. Any links for quick insight and quick building of it? Gentoo specific?

If that turns to be, as it might, the likely path to try. Unless I run out of time I can devote to this ugly issue...

The thing is, what if, by the time I learn building it (I'm afraid it might take long for an intemediate linux user), they come up with the fixed grub2 that loads the kernel and the modules properly for ext4 on md devices...

----------

## SlashBeast

Grub don't need to access to rootfs, grub only need access to boot partition with kernel image, md0 is your boot raid1 yes? Maybe kernel think md0 == rootfs, md1 == boot raid1? Try select root= by UUID or LABEL, I think it will work.

http://jootamam.net/howto-initramfs-image.htm - initramfs howto, initramfs with busybox is imho great rescue shell for raid, lvm etc, you can by hand mount raid with ext4 and try boot it (mount /dev/md0 /newroot && switch_root /newroot /sbin/init).

My modified init from initramfs http://wklej.org/id/52302/ for encrypted rootfs with ext4.

Tip: be sure to emerge buxybox WITH static use flag.

/Sorry about my English./

----------

## miroR

Why have you given me such huge mileage to go?

 :Wink: 

As soon as I am able to find some time I'll give it a try.

English fine.

Polish or Croatian better, but the world has turned anglosaxon since some time, and for some more time...

Polish and Croats are relatives... I like your people...

Thanx for the links and the tips.

www.CroatiaFidelis.hr

www.exDeo.com

----------

## Bones McCracker

I had an existing install and no 2.6.28 livecd available, so I didn't use a cd at all.

 - upgraded the kernel to 2.6.28 (with ext4 support enabled).

 - copied (cp -a) filesystem to spare partition (excluding /proc and /sys)

 - rebooted from copy (modified grub bootline to use temporary root)

 - created new ext4 filesystems on original partitions

 - created mount points and mounted the new partitions to a temporary mount point

 - copied filesystem back to temporary mount point

 - updated fstab to reflect new filesystem types

 - rebooted

In actuality, I didn't have a big enough spare partition for everything at once, so did each of my multiple partitions one at a time (using tar for all but the root partition).  Same difference.

My point is that you can copy (cp -a) your root and boot from the copy, which allows you to use your own kernel, tools, and configuration to make the new ext4 filesystems (including the one for root itself).  Hence, no livecd required (although I'd probably have used one if I had had a reliable 2.6.28 livecd on-hand at the time).

I also removed the "huge_file" feature from ext4 defaults in /etc/mke2fs.conf (replacing it with "large_file") before I created my ext4 filesystems.  Since I will not be storing individual files 2 Terabytes in size, I have no need for that feature and don't need to enable it in the kernel either.

----------

## Tekeli Li

Method 4:

Install basic stage3 + latest portage (unpack the tarballs) into a small partition at the end of the disc (or use a helper, USB disc or stick if you can boot from USB). Install kernel 2.6.28 and setup basic prerequisites (fstab, timezone, stuff like that, upgrade e2fsprogs), boot into it and use that as "minimal install" from which you'll build your real EXT4 partitions, chroot into the real root and install stage3 + kernel again. Unless you have some very complicated partitioning scheme, you should be able to claim back that temporary partition.

After that, just emerge latest portage update, and update/recompile your system.

----------

## Bones McCracker

Method 5:

Wait for btrfs.   :Razz: 

----------

## neuron

anyone know if ext4 has file local fsync yet?

----------

## HotBBQ

I've got ext4 up and running nicely on my system thanks to the SystemRescueCD.  I was curioius as to the possibility of resizing some partitions using gparted without destroying the data.  All of the partitions (/net, /home, /) are ext4.  Is this possible?  Also, is there a ext4 tweaking guide anywhere?

----------

## milomak

what happens if you create a ext3 partition, install as per normal. then convert that partition to ext4?

----------

## HotBBQ

 *milomak wrote:*   

> what happens if you create a ext3 partition, install as per normal. then convert that partition to ext4?

 

From what I have read you will gain most of the performance improvements and maintain forward compatibility.  If you enable extents, though, you will lose that compatibility.  Furthermore, the extents will only apply to new files, not existing ones.

----------

## garlicbread

I thought I'd post this here as it might be of interest to someone

I've currently got a laptop setup under ext3 at the moment,

and I'm in the process of building a second machine / HD (my Work PC) using ext4

by chroot'ing onto the disk directly from the laptop via a USB enclosure

I noticed this recently on slashdot

http://linux.slashdot.org/article.pl?sid=09/03/19/1730247

which follows onto posts here and here

http://www.h-online.com/open/Ext4-data-loss-explanations-and-workarounds--/news/112892

http://thread.gmane.org/gmane.comp.file-systems.ext4/12179

so far I've only been using emerge / console commands to build the system which probably shouldnt't have an issue with fsync

but I figured as soon as I'd use kde4 on the new system (or perahps any form of kde)

this could potentialy be an issue due to fsync

I'm now using "-o data=alloc_on_commit" in the fs options just to be on the safe side when mounting the ext4 system

for info here is the patch I've been using against gentoo-sources-2.6.28-r4

(slightly modified to patch against 2.6.28.9 instead of ext4 git)

Edit

-- patch removed as it doesn't work --Last edited by garlicbread on Mon Mar 23, 2009 9:47 pm; edited 1 time in total

----------

## mv

 *garlicbread wrote:*   

> I'm now using "-o data=alloc_on_commit" in the fs options just to be on the safe side when mounting the ext4 system
> 
> for info here is the patch I've been using against gentoo-sources-2.6.28-r4
> 
> (slightly modified to patch against 2.6.28.9 instead of ext4 git)

 

The patch appears to work as long as there is no "data=alloc_on_commit" in the fstab of the root filesystem. When the latter is the case, it won't remount root rewritable: 

```
mount -o remount,rw /
```

 complains about illegal option. Is this a bug in the patch or have I missed something else (e.g. is the kernel parameter rootfstype=ext4 not enough in this case)? Has anybody else observed this issue?

----------

## garlicbread

from what i understand the patch isn't used unless "data=alloc_on_commit" is in the filesystem options

without it the patch is fairly redundent (not switched on) as your using a different / default data allocation mode

I think it only really applies for apps that have trouble with fsync such as kde, and even then only when the system crashes and restarts

(could result in some of kde's config files being 0 length)

stuff at the console should be fairly safe i'd guess as it probably handles fsync properly

I just tried "mount -o remount,rw /" inside a chroot from the machine I'm using to build from and it seemed to work okay inside the chroot

I haven't gotten as far as booting with the system yet (still building several hundred packages from a copied world file) but I'll look out for this, probably try it inside the sabayon boot cd

for info I'm going to be using an initial 1Gb boot partition (typically ext3) to get around any issues with grub or the initial boot loader

----------

## mv

 *garlicbread wrote:*   

> from what i understand the patch isn't used unless "data=alloc_on_commit" is in the filesystem options

 

Yes, as I said: I have problems only if I use the patch and put "data=alloc_on_commit" in the filesystem options for "/" (which is ext4) in my /etc/fstab. When I use instead "data=ordered" for "/" in /etc/fstab there is no such problem, of course (no matter of whether I use the patch or not). Moreover, the patch causes no problems if I put "data=alloc_on_commit" in /etc/fstab for other ext4 partitions (different from "/") - only for "/" there is this strange problem that it cannot be remounted (I experimented whether I could remount such other partitions as ro and then again as rw - no problem; only "/" has this problem).

 *Quote:*   

> I think it only really applies for apps that have trouble with fsync such as kde, and even then only when the system crashes and restarts
> 
> (could result in some of kde's config files being 0 length)
> 
> stuff at the console should be fairly safe i'd guess as it probably handles fsync properly

 

That's true. However, I would hate myself if I loose kde configuration or perhaps even some text file I was editing (in case my editor does not handle fsync properly) just because I was too lazy to use a patch which was recommended by the ext4 maintainer.

----------

## garlicbread

scrap that patch it doesn't work

I just managed to crash my machine with it  :Smile: 

something oops'd within jbd2

i think the patch in the mailing list is designed for a later version of ext4 than that in the 2.6.28 kernel

as I had to fiddle around to get it to patch against 2.6.28

i think something I may have done in the fiddling to get it to work may have caused the problem

I'll try and hunt around for a version for 2.6.28

I think the ext4 maintaner would proabably perfer if kde fixed thay're fsync code

as at the moment it's relying on a bug / behaviour which is taken for granted within ext3

I think there's been a big discussion about it on some of the blogs

more info here http://suseunbound.lefora.com/2009/03/12/data-loss-may-occurr-when-using-ext4-and-kde-4/page1/

further Edit

couldn't find anyother source of the alloc_on_commit patch for earlier kernels

and I suspect they may be having problems with it anyway, oh well back to ext3 for me  :Smile: 

----------

## shgadwa

Just a note:

I've installed Gentoo on EXT4.... no problem. It was quite easy to do. It did not work with the 2.6.27-gentoo-r8 kernel though. I did a bunch of research and concluded that for my computer, Zen-Sources would do me best. I've installed and configured the 2.6.29-rc7-zen1 Zen Sources Kernel, and I couldn't of been happier with the setup. EXT4 works great and so far I have not had any problems with my kernel, or the file system.

----------

## garlicbread

I think it all depends on which form of X windowing system your using

for general use ext4 should be fine, it just seems to be certain apps that don't implement fsync properly that could cause a problem

the only one I'm aware of is KDE4, which could result in data loss in the kde config files, as it's depending on behavior observed in ext3 which is technically classed as a bug

----------

## mv

 *garlicbread wrote:*   

> for general use ext4 should be fine

  That's true, I also had no problems with it so far, although I use KDE.

 *Quote:*   

> it just seems to be certain apps that don't implement fsync properly that could cause a problem

 

Sorry, but I completely disagree: That's just a lame excuse of Ted Ts'o. Except for very exceptional purposes no program should ever have a reason to call fsync - just saving a new version of some existing file is certainly no such reason: Why should it be in the responsibility of the application to ensure that every single file it changes is saved to disk? This would undermine all the purpose of caching filesystems. (It would be different, if fsync() would not guarantee to write to disk but instead to set a barrier; however, such a "barrier()" command does not exist in POSIX).

It is the task of the filesystem to write the data to disk when it is appropriate and in such an order that it makes sense if a crash should occur: The filesystem receives the calls in the appropriate order and has to make sense from them - if it reorders the tasks for caching purposes, it (the filesystem code) is responsible that the reordering still is correct: Only the filesystem code has possibilities like setting barriers at the appropriate points etc. That also other filesystems fail to do this correctly is no real excuse. The alloc_on_commit strategy is probably the most correct solution (a real implementation of atomic operations would be more appropriate, but for this we have to wait for Reiser4 stabilization [which probably will never happen, unfortunately] or some unknown new filesystem).

----------

## garlicbread

Not to misunderstand I wasn't trying to point the finger and say it's an application issue, or it's a filesystem issue

only that the sofware affected by the issue appears to be limited to a select few apps such as kde4, wherever the fault may be

although it would be interesting to see if there was any low level console apps affected by this as well

to be honest I don't know enough about filesystems to say one way or the other

as near as I can tell part of the discussions seem to sit around the definition or meaning of fsync, or at least it's intended use

speaking generally, if an issue or change affects only one application and not multiple applications, then I'm more likley to be believe it's an issue specific to that application

If the issue affects multiple applications (e.g. older versions of KDE for example) then I'd be more likley to believe it's a filesystem issue

ideally you'd need more information as to which apps could be affected by the issue to say one way or the other (I have no idea)

As near as I can tell as a general rule of thumb

if you've been building a system just using a chroot and emerge at the command line, something that perhaps acts as a server then your probably fine

in my case since I will be using kde 4.2 it's just something I need to avoid untill it's all been straightened out by the kernel devs or the kde devs depending on your point of view

I was hopefull that the alloc_on_commit patch would have been a quick fix to the problem, even if it sacrificed performance

however after locking my machine with it, that's definitley right out for the time being at least

----------

