Mailing List Archive

Am 28.10.2010 18:32, schrieb Martin Herrman:
> Hello all,
>
> did any of you convert from ext3 to ext4?
>

Yep.

> Does it improve performance noticably for a default workstation?
> (firefox, openoffice, amarok (with large database), kopete, skype)
>

It depends. Actions on large files, especially deleting or truncating
them, is much faster now (nearly instantly where it was several seconds
with ext3). Overall performance "feels good" but it of course cannot
overcome the limits of an HDD.

> Will you eventually be fine when just converting an existing system,
> or is a reinstall preferred? (which is much more effort)
>

Conversion is fine. It will start using extents (the main advantage) for
new files. I don't know what it does for new allocations to old files.

> https://help.ubuntu.com/community/ConvertFilesystemToExt4
>
> Does a raid setup require extra attention? (I'm running /dev/md1 in
> raid-1 for /boot and /dev/md3 in raid-0 for /) Do I have to convert
> /dev/md3, or the /dev/sda3 and /dev/sdb3?
>

Raid-1 does not need any attention (IMHO) but you should apply some
tweaking to Raid-0. However, that is also true to Ext3 and the
parameters should not have changed. So the setup can stay the same.

Hope this helps,
Florian Philipp

On Thu, Oct 28, 2010 at 06:32:59PM +0200, Martin Herrman wrote:
> Will you eventually be fine when just converting an existing system,
> or is a reinstall preferred? (which is much more effort)

It appears that a reinstall or copying files all around would be more
effort :-p.

> https://help.ubuntu.com/community/ConvertFilesystemToExt4
>
> Does a raid setup require extra attention? (I'm running /dev/md1 in
> raid-1 for /boot and /dev/md3 in raid-0 for /) Do I have to convert
> /dev/md3, or the /dev/sda3 and /dev/sdb3?

If /dev/sda3 and /dev/sdb3 both constitute /dev/md3, then you should
run any conversion on /dev/md3. If you run conversion on /dev/sda3 or
/dev/sdb3 independantly of eachother and the tool actually does
something, it's possible that the two mirrors would become
inconsistent with eachother. I'm not sure, but I _think_ that if
/dev/sda3 and /dev/sdb3 form /dev/md3, then there's a little extra
md-specific metadata which would prevent tune2fs from recognizing
/dev/sda3 and /dev/sdb3 as ext3 partitions -- which should protect you
from accidentally operating directly on these partitions instead of
the /dev/md3 device.

--
binki

Look out for missing apostrophes!

Hi Nathan and Florian,

thanks for both your replies. Running / in ext4 now :-)

tunefs command was really quick (which I didn't expect), but during
the reboot I had to run an fsck manually. Dmesg now shows me that the
filesystem has some unknown attributes to ext3 and next mounts it as
ext4.

Just another 2 questions:
- Florian, what kind of tuning for raid-0 are you pointing at? (i only
have the noatime in /etc/fstab)
- I read that increasing the commit field will increase the amount of
data that can be lost in a power failure, but increases performance.
When I put it in /etc/fstab, for example with a value of 30 seconds,
the /etc/mtab file shows me 'noatime,commit=30,noatime=0'. Dmesg final
line says "EXT4-fs (md3): re-mounted. Opts: commit=0". Should I
increse this value, and how?

Thanks,

Martin

Am 29.10.2010 07:56, schrieb Martin Herrman:
> Hi Nathan and Florian,
>
> thanks for both your replies. Running / in ext4 now :-)
>
> tunefs command was really quick (which I didn't expect), but during
> the reboot I had to run an fsck manually. Dmesg now shows me that the
> filesystem has some unknown attributes to ext3 and next mounts it as
> ext4.
>
> Just another 2 questions:
> - Florian, what kind of tuning for raid-0 are you pointing at? (i only
> have the noatime in /etc/fstab)

See question 9 here:
http://tldp.org/HOWTO/Software-RAID-0.4x-HOWTO-8.html

and also the calculator here:
http://busybox.net/~aldot/mkfs_stride.html

There might be more alignment issues with LVM on RAID. I don't think it
will be a problem as long as LVM's physical extent size (default 4MB) is
a multiple of the RAID stripe size (default 64kB?). Someone with more
experience in these setups than me might want to comment on my guess.

2010/10/31 Florian Philipp <lists@f_philipp.fastmail.net>
>
> See question 9 here:
> http://tldp.org/HOWTO/Software-RAID-0.4x-HOWTO-8.html
>
> and also the calculator here:
> http://busybox.net/~aldot/mkfs_stride.html
>
> There might be more alignment issues with LVM on RAID. I don't think it
> will be a problem as long as LVM's physical extent size (default 4MB) is
> a multiple of the RAID stripe size (default 64kB?). Someone with more
> experience in these setups than me might want to comment on my guess.

Okay, so after a holiday trip, some hard weeks of labour, I went ill.
During recovery I decided to dive into this issue again :-)

I found out that my current chunk size is 64K:

martindesktop ~ # mdadm -Q --detail /dev/md3
<cut>
Chunk Size : 64K
<cut>
martindesktop ~ #

and my block size is 4KiB:

martindesktop ~ # /sbin/dumpe2fs /dev/sda3 | grep 'Block size'
<cut>
Block size: 4096
<cut>
martindesktop ~ #

The calculator output is:

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32

The maintained RAID howto at:

https://raid.wiki.kernel.org/index.php/RAID_setup

says that stride and stride-width can be changed afterwards by using:

tune2fs -E stride=n,stripe-width=m /dev/mdx

So that's what I did:

martindesktop / # tune2fs -E stride=16,stripe-width=32 /dev/md3
tune2fs 1.41.12 (17-May-2010)
Setting stride size to 16
Setting stripe width to 32
martindesktop / #

(this took less than a second)

I also read the mdadmin man-page. It looks like one can adjust the
chunk size (also for RAID-0) without repartitioning, but I found
(using google) no hard evidence that 64K is a wrong choice for a
desktop system. I won't perform my own benchmarks (based on what??)
and will stick with the 64K.

Regards,

Martin