I searched through linode forums but could not find my issue discussed there.

I needed latest kernel available(linode has "Latest 3.0 [3.0.4-linode38]), ext4 filesystem on ubuntu LTS 10.04 for a database server. Since EXT4 support is built in the kernel and linode does not yet support it via GUI, I converted ext3 FS to ext4 myself in following steps

1. Replaced "ext3" with "ext4" for my root filesystem in /etc/fstab
2. Rebooted into single user mode after setting proper single usermode switch from Linode Slice manager.
3. Ran tune2fs -O extents,uninit_bg,dir_index /dev/xvda
4. Rebooted again into single user mode
5. Ran e2fsck -y -fDC0 /dev/xvda to patch up the filesystem.
6. Finally rebooted normally.


Now, it seemed fine after first successful reboot

cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext4 rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered 0 0

-----cropped

But it seems in every reboot, i get

EXT4-fs error (device xvda): ext4_journal_start_sb:296: Detected aborted journal
EXT4-fs (xvda): Remounting filesystem read-only

Subsequent reboot fixes this by forced run of fsck.


It works fine until next reboot and it happens again.

Any known issues sir ?

Is this related to following bug :

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637234


I changed the linode profile from latest 3 to latest 2.6.X , the system behaved normally. So this is only happening to 3.X line of kernel !!!!!

I'd say it sounds a lot like that bug.

Any particular reason for switching to ext4? Keep in mind that the hosts run pre-ext4 kernels and might not be able to resize or mount the filesystem now.

_________________

/* TODO: need to add signature to posts */

I already have a mongodb instance running under 32 bit /ext3 system. After cross-examining few things, came to realize 64 bit + ext4 file system can push the performance especially since MongoDB works under the paradigm of memory-mapped files. Also it is mentioned under Production deployment tips @MongoDB site.

Yeah, a kernel bug. It also affects ext3 on 3.1 since barriers are now enabled by default. (I suspect this is why the 3.1 kernel is marked "broken" by Linode). You can work around it by disabling barriers until an updated kernel with a fix is released. You'll have to weigh the implications yourself. I'm not sure how barriers work in a virtualized environment anyway since the device the OS is writing to isn't a physical hard drive.

I guess i will have to wait and see to get this fixed.

Thank you very much people

In the meantime you could also try disabling barriers on your ext4 mounts, since from the ticket that would seem to be a workaround.

Given the underlying disk subsystem (BBU-backed RAID array), I'm not sure barriers really buy that much in a Linode VPS anyway. Once the data is handed to the I/O subsystem it really ought to (eventually) get to the physical media even if some reordering takes place.

-- David

I added the barrier=0 option to my fstab for my ext3 partitions, and am able to boot the "broken" 3.1 kernel just fine. Time will tell if there is any impact on fault tolerance.

3.2.1 boots just fine with barriers enabled.

I disabled barriers in our kernels by default.

-Chris

Has this issue been fixed? I just converted to ext4 and had a similar issue on first boot, but I'm not sure if it's just a one-time thing related to the conversion or if it's going to be a recurring problem for me.
Do I still need the barriers=0?
Using latest(Latest 3.5 (3.5.2-linode45))

I'm having a hard time understanding how a VM with ext4 could see a performance improvement when running on a host with ext3. In the end the disk image is still sitting on an ext3 filesystem.

_________________

/* TODO: need to add signature to posts */

Ah! I mis-interpereted what pre-ext4 kernel meant in that reply. Interesting method of just feeding the VM a raw LVM mount for its disk image.