# strange reiserfs size problem

## noup

hi everyone.

a strange thing happened to my /boot partition, so i was wondering wether it's a feature or bug.

i had a /boot partition of 40MB with reiserfs 3.6. today, i noticed it was completely full. i went to check and there were actually only 6MB of files, but "df" reported the partition was 100% full.

so i ran reiserfscsk with all the modes and some "lost+found" directory appeared in my partition. i thought if i deleted it then the free space would come to normal, but that didn't happen.

after all tries i decided to format my /boot partition with ext3.

so, now i'm wondering, is this normal? i also have another 3 partitions formated with reiserfs, will this happen to them?

----------

## jkt

(please, no flame)

another problem with reiser....

look at list of opened bugs of reiserfs in bugzilla.kernel.org, namesys folks seems quite unresponsive...

----------

## noup

i didn't get to find any bug related to mine..

though, i never had problems with reiserfs before. could it be due to the "notail" option i used in fstab? strange..

----------

## jkt

"notail" option is required for grub to operate, AFAIK.

And link to bugzilla.kernel.org was intended to point out that there are bugs in reiserfs and namesys team doesn't respond to reports of them.

----------

## mr666white

I have a sneaking suspicion that the journal tends to take up a lot of space and is inefficient on small disks. The standard approach for /boot is to use ext2 (non journaling) and use the noauto option in fstab so boot ounl mounts when you need it. Given the size and number of partitions on a boot partition, it doesn't take too long to fsck it, and the main advantage of a journal is you can check your data for consistency faster.

----------

## jkt

yep, you're right. BTW, suggested size for /boot is 64MB for journaled filesystems, according to gentoo handbook.

----------

## noup

 *mr666white wrote:*   

> I have a sneaking suspicion that the journal tends to take up a lot of space and is inefficient on small disks. The standard approach for /boot is to use ext2 (non journaling) and use the noauto option in fstab so boot ounl mounts when you need it. Given the size and number of partitions on a boot partition, it doesn't take too long to fsck it, and the main advantage of a journal is you can check your data for consistency faster.

 

that makes sense.

though, if those 36MB of mine (that were supposed to be free) were occupied by the journal, why did it appear in the form of some files (some of which have the same names as the ones in grub's dir) in the lost+found dir, after running reiserfscsk?

----------

## jkt

as I said, reiserfs does have known bugs which remain unfixed. That quite a good reason for me not to use it. (But I must admit, I still have some reiser 3.6 partitions on my systems, but it's only because I have backups and don't want to disturb production environment.)

----------

## noup

 *jkt wrote:*   

> as I said, reiserfs does have known bugs which remain unfixed. That quite a good reason for me not to use it. (But I must admit, I still have some reiser 3.6 partitions on my systems, but it's only because I have backups and don't want to disturb production environment.)

 

i see, that's quite a reason for not to choose it. what do you sugest in replacement, ext3?  :Smile: 

----------

## mr666white

ReiserFS is fine on larger partitions and it's not reason to stop using it, but it causes problems on small partitions. Don't even try to boot from a reiser4 partition, it's more trouble than it's worth, but again for eveything else but /boot it's fine.

Ext 2 for boot partitions and stick the noauto tag into your fstab.

ext3 is so horribly slow I wouldn't reccommend using it, however it is the best supported. and if boot times are not an issue then it's fine on a boot partition. 

XFS is worth a try, but it's not that well supported compaired to reiserfs and ext3

----------

## Bob P

nevermind

----------

## jkt

 *mr666white wrote:*   

> ReiserFS is fine on larger partitions and it's not reason to stop using it, but it causes problems on small partitions. Don't even try to boot from a reiser4 partition, it's more trouble than it's worth, but again for eveything else but /boot it's fine.
> 
> Ext 2 for boot partitions and stick the noauto tag into your fstab.
> 
> ext3 is so horribly slow I wouldn't reccommend using it, however it is the best supported. 
> ...

 

and flame is here  :Sad: .statements like "ext3 is slow" are not true, ext3 can perform worse than reiser, of course, but only under some circumstances. I can simultae another situation where ext3 will be many times faster.

if I see messages saying "kernel BUG at fs/reiserfs/journal.c:519!" and namesys folks don't even bother to respond to bugreport (kernel bug#2984) for more than five months, it's quite a big reason for me to re-mkfs my reiserfs partitions with another fs.

 *Quote:*   

> 
> 
> and if boot times are not an issue then it's fine on a boot partition. 
> 
> 

 

what are you talking about?

a) having journal on 32MB boot partition is useless. how long does it take to make fsck on partition < 100MB using UATA/33 or newer??

b) what is slow on ext3 as boot? reading <3MB bzImage + 2MB initrd?? are you joking??

aren't you just spreading FUD?

 *Quote:*   

> 
> 
> XFS is worth a try, but it's not that well supported compaired to reiserfs and ext3

 

according to gentoo handbook, xfs is recommended only on"hi-end" scsi/fiber channel systems having UPS. btw, do you know about a bug that should cause xfs to shrink files written after last umount? quite fatal for /boot...

 *Bob P wrote:*   

> 
> 
> just for reference, i made my /boot partition 1024 MB in size for use with Reiser FS 3.6.  looking back, i wish that i had made it larger. 
> 
> 

 

what are you storing on /boot? I wonder that 1GB is not enough for you... even my rootfs is smaller  :Wink: 

----------

## Bob P

oops.  my /boot is 100 MB.  dunno why i said it was a gig.    :Embarassed: 

----------

## jkt

 *Bob P wrote:*   

> oops.  my /boot is 100 MB.  dunno why i said it was a gig.   

 

ok, that seems wise. anyway, why are you storing kernels for another machines on /boot? According to FHS, it is for "data that is used before the kernel begins executing user-mode programs."

"Better" should be to put them somewhere else, near your other files for diskless clients. But that's completely your business, of course  :Wink: 

----------

## asimon

Regarding boot times and filesystem choice:

When it comes to the speed of the boot process the filesystem choice is an absolute non-issue. Anybody who even does some half-serious boot profiling will see that. Some Ubuntu developers are currently in the process to dramatically improve the boot time of their distribution and did some serious profiling (including nice graphical charts) to see where the time actually is spend during booting. I recommend to read their blogs about it. Choosing an other filesystem in the hope to make the machine boot faster is pointless.

The size of the journal of reiserfs is mentioned in the man page of mkreiserfs, but is measured there in cryptic blocks. Maybe it's a good idea to make a comment on this in the install guide. Reiserfs for /boot (or generally very small partitions) should not be recommended.

It was absolutely new to me that there are many serious open bug reports for reiserfs at kernel.org and that the authors are unresponsive to these bugs. I haven't yet look at those bug reports but it sounds bad.

----------

## noup

 *asimon wrote:*   

> Some Ubuntu developers are currently in the process to dramatically improve the boot time of their distribution and did some serious profiling (including nice graphical charts) to see where the time actually is spend during booting. I recommend to read their blogs about it. Choosing an other filesystem in the hope to make the machine boot faster is pointless.

 

i've searched a bit and didn't get to find those blogs. could you point out some links?  :Smile: 

----------

## asimon

 *noup wrote:*   

> i've searched a bit and didn't get to find those blogs. could you point out some links? 

 

Of course. I saw them at Planet Debian. Look especially at the blogs from Erich Schubert and Daniel Stone. They use readahead from Fedora, do some patching to gdm and the xserver and probably other stuff. So far they have gone from over 90 seconds from Wary to just 45 seconds in their development trunk until a ready gdm login screen. Not bad.

I doubt that switching to an other filesystem would give you more than a second.

----------

## jkt

 *asimon wrote:*   

> It was absolutely new to me that there are many serious open bug reports for reiserfs at kernel.org and that the authors are unresponsive to these bugs. I haven't yet look at those bug reports but it sounds bad.

 

It was new for me, too  :Sad: . I wonder why are they making new versions of their super-cool filesystem and don't bother to fix older versions...

----------

## noup

 *asimon wrote:*   

>  *noup wrote:*   i've searched a bit and didn't get to find those blogs. could you point out some links?  
> 
> Of course. I saw them at Planet Debian. Look especially at the blogs from Erich Schubert and Daniel Stone. They use readahead from Fedora, do some patching to gdm and the xserver and probably other stuff. So far they have gone from over 90 seconds from Wary to just 45 seconds in their development trunk until a ready gdm login screen. Not bad.
> 
> I doubt that switching to an other filesystem would give you more than a second.

 

Thank you. Daniel Stone's blog doesn't seem to be online, but still, i found the remaining posts interesting. 30 seconds till gdm looks really nice.  :Smile: 

now for gentoo matters, are there any howtos about speeding boot up (except for the "flying with gentoo one", i've read that one already)?

----------

## jkt

 *noup wrote:*   

> now for gentoo matters, are there any howtos about speeding boot up (except for the "flying with gentoo one", i've read that one already)?

 

you can try to move xdm from default to boot runlevel. not verified, though...

----------

## Leffe

```
# du -sbmx /; df /dev/hda4

 1167   /

Filesystem            Size  Used Avail Use% Mounted on

/dev/hda4             2.3G  1.6G  698M  70% /
```

ReiserFS wins.

----------

## asimon

 *noup wrote:*   

> now for gentoo matters, are there any howtos about speeding boot up (except for the "flying with gentoo one", i've read that one already)?

 

For the really bold, see bug #64724 and bug #69579.

----------

## noup

 *jkt wrote:*   

> 
> 
> you can try to move xdm from default to boot runlevel. not verified, though...

 

i don't even use xdm, since i always thought it was faster to boot->logon user->startx, and that xdm would slow things down (since i don't need the user-switching thing).

is it necessary?  :Smile:  or, put in another way, does the expense of running xdm compensate the advantage of a faster booting time (in your opinion)?  :Smile: 

----------

## noup

 *asimon wrote:*   

> 
> 
> For the really bold, see bug #64724 and bug #69579.

 

looks like there is going a lot more than i thought about this on gentoo, great.  :Smile: 

----------

## jkt

 *noup wrote:*   

>  *jkt wrote:*   
> 
> you can try to move xdm from default to boot runlevel. not verified, though... 
> 
> i don't even use xdm, since i always thought it was faster to boot->logon user->startx, and that xdm would slow things down (since i don't need the user-switching thing).
> ...

 

As I am a lazy^h^h^h^hKDE user  :Wink: , it's easier for me just to use KDE's xdm, it saves me typing "startx"  :Smile: . Actually, I don't think that there'll be big differences, but I haven't tried (neither have any plans to do it).

----------

## noup

 *jkt wrote:*   

> 
> 
> As I am a lazy^h^h^h^hKDE user , it's easier for me just to use KDE's xdm, it saves me typing "startx" . Actually, I don't think that there'll be big differences, but I haven't tried (neither have any plans to do it).

 

heh... i'm not trying that either. but i intend on trying some other boot tunning. later......  :Smile: 

----------

