Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Zen Kernel Discussion/Support Thread - Part 2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 11, 12, 13, 14  Next  
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
cheater1034
Veteran
Veteran


Joined: 09 Sep 2004
Posts: 1558

PostPosted: Thu Jan 28, 2010 4:10 am    Post subject: Reply with quote

Shining Arcanine wrote:
Saundersx wrote:
Whats the deal with Reiser4 and current kernels? Has it gone the way of the dodo?

And also what are the odds if I go with btrfs that I'll lose everything in a catastrophic spectacular fashion?

I recently reinstalled everything and went all reiser3 just to use the newest kernel. I was re-introduced to that annoying firefox3+reiser3 sluggish startup that is so annoying.


I lost everything within a day when I mounted my root partition on my ssd with ssd,compress,noatime on the 2.6.33-rc4 kernel. If you try btrfs, you will probably lose everything too.


The problems with reiser4 on 2.6.32+ kernels has been discussed thoroughly already. It's a consequence of using an FS that has a fairly inactive maintainer. Reiser4 is a poor option as a desktop for anybody due to the HORRIBLE fsync performance (i'm not saying you use it on a desktop, but most on this forum are), and it's just a poor choice. Reiser4 has an extremely rocky history and has barely been changed in the last 2-3 years, I'd consider it approaching death but it is hanging around and some still have confidence in it (but that confidence is fading)

Using it on an ssd is an even worse choice ^^^

"If you try btrfs, you will probably lose everything too" - This is simply a wrong generalization. Obviously there is a risk with all experimental software that there will be bugs, however btrfs has a massive amount of testers (unlike reiser4 currently), and there is no presently major bug report open. Anything that's out there is very minor, and most issues have been addressed. The FS is getting closer and closer to completion, perhaps there are one or two missing features yet, but I'm not totally sure what else is planned. --- There is an EXTREMELY rare chance that you would lose all of your data - by extremely rare - i mean 1-5% at the most, any problems like this simply wouldnt have been overlooked for this long, there's always an off chance of data corruption due to a bug, but the whole partition isn't going to just format itself. You have a better chance at loosing data on ext4 when using writeback (like my data loss on ext4 :P)

Btrfs is presently (2.6.33+, or 2.6.32-zen+) also the fastest FS in the kernel in nearly every category, save for reiserfs when handling tons of small files apparently - ignore most of the phoronix benchmarks too as they are flat out poorly done or irrelevant - how did they come up with the conclusion that ext3 is the fastest FS in the kernel? We dicussed it in IRC already so you should have been there if you want me to explain what's wrong with them :P

I've been meaning to tag reiser4 as broken, not sure why nobody else has yet - but I've been way too busy with other stuff to do much work on zen lately, and when I do get time the biggest focus right now is working on BFQ, which will be a little bit lengthy of a job.
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land.
Back to top
View user's profile Send private message
Twenynge
n00b
n00b


Joined: 08 Jan 2010
Posts: 56

PostPosted: Thu Jan 28, 2010 4:51 am    Post subject: Compiled Zen Kernel, Nvidia won't Load Reply with quote

Just finished compiling OMFG 2010!, added a grub entry and booted, and my nvidia module refuses to load. In fact, the module itself seems to have disappeared completely. It is not shown durning a lsmod even though I have emerged it since installing the new kernel. Modprobe nvidia returns "FATAL: Module nvidia not found." I have verified that my kernel supports module loading and that I do not have the nvidiafb installed. Anybody have any idea how to troubleshoot this?
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Thu Jan 28, 2010 5:12 am    Post subject: Reply with quote

module-rebuild
http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap6
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
Twenynge
n00b
n00b


Joined: 08 Jan 2010
Posts: 56

PostPosted: Thu Jan 28, 2010 5:40 am    Post subject: Reply with quote

ppurka wrote:
module-rebuild
http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap6


As I said, I emerged nvidia-drivers (multiple times, actually) when using the new kernel. I emerged module-rebuild just to check, and I get the same results. Modprobe nvidia still gives the fatal error.
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Thu Jan 28, 2010 5:41 am    Post subject: Reply with quote

cheater1034 wrote:
There is an EXTREMELY rare chance that you would lose all of your data - by extremely rare - i mean 1-5% at the most

8O :o <cough><cough> ROFL

I would hope your chances are better than 1-5%.

But it's an interesting time for FS selection right now. Reiser4 is MIA. Reiser3 is, well, Reiser3. Btrfs is experimental. And Ext4 has all this talk of performance regressions.

It's a really good time to review your data backup strategies. :)
Back to top
View user's profile Send private message
ppurka
Advocate
Advocate


Joined: 26 Dec 2004
Posts: 3256

PostPosted: Thu Jan 28, 2010 6:05 am    Post subject: Reply with quote

Twenynge wrote:
ppurka wrote:
module-rebuild
http://www.gentoo.org/doc/en/kernel-upgrade.xml#doc_chap6


As I said, I emerged nvidia-drivers (multiple times, actually) when using the new kernel. I emerged module-rebuild just to check, and I get the same results. Modprobe nvidia still gives the fatal error.
Check that your symlink in /usr/src points to the correct kernel. There is no reason why emerge will succeed and then you will get a "module not found" error.
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/
Back to top
View user's profile Send private message
erpalma
n00b
n00b


Joined: 19 Feb 2008
Posts: 17

PostPosted: Thu Jan 28, 2010 10:32 am    Post subject: Reply with quote

cheater1034 wrote:

Btrfs is presently (2.6.33+, or 2.6.32-zen+) also the fastest FS in the kernel in nearly every category, save for reiserfs when handling tons of small files apparently - ignore most of the phoronix benchmarks too as they are flat out poorly done or irrelevant - how did they come up with the conclusion that ext3 is the fastest FS in the kernel? We dicussed it in IRC already so you should have been there if you want me to explain what's wrong with them :P


Just tried to decompress a 2.6.32 kernel tar (not gzipped) to my OCZ Vertex 30GB with ext4 and btrfs partitions from tmpfs. Currently I'm using zen 2.6.33-rc5 with btrfs ssd+discard and ext4 without journal and data=writeback barrier=0 nobh commit=30 discard. Ext4 is MUCH faster than btrfs (40% if I remember correctly). Didn't try with bigger files.
Back to top
View user's profile Send private message
dodo1122
Guru
Guru


Joined: 02 Sep 2006
Posts: 347
Location: York, England

PostPosted: Thu Jan 28, 2010 12:25 pm    Post subject: Reply with quote

Saundersx wrote:
Whats the deal with Reiser4 and current kernels? Has it gone the way of the dodo?

And also what are the odds if I go with btrfs that I'll lose everything in a catastrophic spectacular fashion?

I recently reinstalled everything and went all reiser3 just to use the newest kernel. I was re-introduced to that annoying firefox3+reiser3 sluggish startup that is so annoying.


Insensitive clod! :P

erpalma wrote:
Just tried to decompress a 2.6.32 kernel tar (not gzipped) to my OCZ Vertex 30GB with ext4 and btrfs partitions from tmpfs. Currently I'm using zen 2.6.33-rc5 with btrfs ssd+discard and ext4 without journal and data=writeback barrier=0 nobh commit=30 discard. Ext4 is MUCH faster than btrfs (40% if I remember correctly). Didn't try with bigger files.


well obviously using no barriers would make ext4 wayyy faster... and a lot more prone to fuckups ;P
_________________
#zen-sources on irc.rizon.net
Back to top
View user's profile Send private message
erpalma
n00b
n00b


Joined: 19 Feb 2008
Posts: 17

PostPosted: Thu Jan 28, 2010 12:59 pm    Post subject: Reply with quote

dodo1122 wrote:
well obviously using no barriers would make ext4 wayyy faster... and a lot more prone to fuckups ;P


I know but in 6 month absolutely no data lost (with MANY reset)! I hope BTRFS will become THE linux FS.
Back to top
View user's profile Send private message
dusanc
Apprentice
Apprentice


Joined: 19 Sep 2005
Posts: 248
Location: Serbia

PostPosted: Thu Jan 28, 2010 4:02 pm    Post subject: Reply with quote

cheater1034 wrote:
... Reiser4 is a poor option as a desktop for anybody due to the HORRIBLE fsync performance (i'm not saying you use it on a desktop, but most on this forum are), and it's just a poor choice...

Could you point me to the source of this claim? I mean poor fsync performance (when fs does data to platter fsync, not something like no barrier option :) or large commit intervals).
I'd like to digg into it.

Thanks
_________________
Reiser4 Gentoo FAQ [25Dec2016]
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jan 28, 2010 4:46 pm    Post subject: Reply with quote

dusanc wrote:
cheater1034 wrote:
... Reiser4 is a poor option as a desktop for anybody due to the HORRIBLE fsync performance (i'm not saying you use it on a desktop, but most on this forum are), and it's just a poor choice...

Could you point me to the source of this claim? I mean poor fsync performance (when fs does data to platter fsync, not something like no barrier option :) or large commit intervals).
I'd like to digg into it.

Thanks


just do the following:

extract a portage-tarball to a reiser4-partition, rsync the tree (update it), then chown -R portage:portage /usr/portage (or where that partition is mounted)

then do cat /proc/meminfo (to see how many data is in cache)

time sync (in general the first time after extracting the stuff to the partition is pretty fast - the following times syncing is abysmal slow: usually around 300-500 kB per seconds)

sync the tree again after some time, chown -R portage:portage /usr/portage


see again how many files are in cache: cat /proc/meminfo

again NOW do: time sync


you'll see that it'll take AGES to put stuff to the partition

*) this happens with regular reiser4-partition
*) and reiser4-partition that use the ccreg40 "plugin" with lzo or gzip-compression


generally this took 3-5 minutes for me with reiser4 or longer (depending on the kernel-release)


with btrfs (with compression) and ext4 this takes several seconds


sometimes you simply need to shut down the computer and those cases it really s*** :evil:


when you are not dependent that the data is synced to the partition you can simply let reiser4 sync it over time and (from my experience) it won't affect read or write-performance negatively while reiser4 handles this transparently in the background - which is a BIG advantage over the other filesystems



hope that helps :)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Saundersx
Apprentice
Apprentice


Joined: 11 Apr 2005
Posts: 251

PostPosted: Thu Jan 28, 2010 5:17 pm    Post subject: Reply with quote

cheater1034 wrote:
Shining Arcanine wrote:
Saundersx wrote:
Whats the deal with Reiser4 and current kernels? Has it gone the way of the dodo?

And also what are the odds if I go with btrfs that I'll lose everything in a catastrophic spectacular fashion?

I recently reinstalled everything and went all reiser3 just to use the newest kernel. I was re-introduced to that annoying firefox3+reiser3 sluggish startup that is so annoying.


I lost everything within a day when I mounted my root partition on my ssd with ssd,compress,noatime on the 2.6.33-rc4 kernel. If you try btrfs, you will probably lose everything too.


The problems with reiser4 on 2.6.32+ kernels has been discussed thoroughly already. It's a consequence of using an FS that has a fairly inactive maintainer. Reiser4 is a poor option as a desktop for anybody due to the HORRIBLE fsync performance (i'm not saying you use it on a desktop, but most on this forum are), and it's just a poor choice. Reiser4 has an extremely rocky history and has barely been changed in the last 2-3 years, I'd consider it approaching death but it is hanging around and some still have confidence in it (but that confidence is fading)

Using it on an ssd is an even worse choice ^^^

"If you try btrfs, you will probably lose everything too" - This is simply a wrong generalization. Obviously there is a risk with all experimental software that there will be bugs, however btrfs has a massive amount of testers (unlike reiser4 currently), and there is no presently major bug report open. Anything that's out there is very minor, and most issues have been addressed. The FS is getting closer and closer to completion, perhaps there are one or two missing features yet, but I'm not totally sure what else is planned. --- There is an EXTREMELY rare chance that you would lose all of your data - by extremely rare - i mean 1-5% at the most, any problems like this simply wouldnt have been overlooked for this long, there's always an off chance of data corruption due to a bug, but the whole partition isn't going to just format itself. You have a better chance at loosing data on ext4 when using writeback (like my data loss on ext4 :P)

Btrfs is presently (2.6.33+, or 2.6.32-zen+) also the fastest FS in the kernel in nearly every category, save for reiserfs when handling tons of small files apparently - ignore most of the phoronix benchmarks too as they are flat out poorly done or irrelevant - how did they come up with the conclusion that ext3 is the fastest FS in the kernel? We dicussed it in IRC already so you should have been there if you want me to explain what's wrong with them :P

I've been meaning to tag reiser4 as broken, not sure why nobody else has yet - but I've been way too busy with other stuff to do much work on zen lately, and when I do get time the biggest focus right now is working on BFQ, which will be a little bit lengthy of a job.


I'm just going by what I read on the btrfs thread here https://forums.gentoo.org/viewtopic-t-565360-highlight-btrfs.html

I've been pretty lucky with reiser4. The only issue is when compiling gcc, like clockwork it would orphan an undeletable file in tmp, almost every time, strangely... But yeah I've moved on from that now.

Going to throw btrfs on a partition and see how it goes, not /home obviously :D
Back to top
View user's profile Send private message
dusanc
Apprentice
Apprentice


Joined: 19 Sep 2005
Posts: 248
Location: Serbia

PostPosted: Thu Jan 28, 2010 5:35 pm    Post subject: Reply with quote

kernelOfTruth wrote:
dusanc wrote:
cheater1034 wrote:
... Reiser4 is a poor option as a desktop for anybody due to the HORRIBLE fsync performance (i'm not saying you use it on a desktop, but most on this forum are), and it's just a poor choice...

Could you point me to the source of this claim? I mean poor fsync performance (when fs does data to platter fsync, not something like no barrier option :) or large commit intervals).
I'd like to digg into it.

Thanks


just do the following:

extract a portage-tarball to a reiser4-partition, rsync the tree (update it), then chown -R portage:portage /usr/portage (or where that partition is mounted)

then do cat /proc/meminfo (to see how many data is in cache)

time sync (in general the first time after extracting the stuff to the partition is pretty fast - the following times syncing is abysmal slow: usually around 300-500 kB per seconds)

sync the tree again after some time, chown -R portage:portage /usr/portage


see again how many files are in cache: cat /proc/meminfo

again NOW do: time sync

you'll see that it'll take AGES to put stuff to the partition

*) this happens with regular reiser4-partition
*) and reiser4-partition that use the ccreg40 "plugin" with lzo or gzip-compression

generally this took 3-5 minutes for me with reiser4 or longer (depending on the kernel-release)

with btrfs (with compression) and ext4 this takes several seconds

sometimes you simply need to shut down the computer and those cases it really s*** :evil:

when you are not dependent that the data is synced to the partition you can simply let reiser4 sync it over time and (from my experience) it won't affect read or write-performance negatively while reiser4 handles this transparently in the background - which is a BIG advantage over the other filesystems

hope that helps :)


Thanks KoT
Reproduced it :) writes at 80-100kb/s
This is slow file attrib modification, not bad sync, I think it's because bad layout. It syncs allright but cause it has to modify a bunch of attributes (small data) that's everywhere it's slow.
Do U have some other testcase that gives bad write throughput?
Cause this looks like no slow sync, just bad attributes layout.
_________________
Reiser4 Gentoo FAQ [25Dec2016]
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jan 28, 2010 5:48 pm    Post subject: Reply with quote

do the same test without chown -R portage:portage

basically:

1)
*) extracting the portage-tarball
*) syncing the portage tree
*) time sync

-> rather fast the first time

2)
*) sync the portage tree again
*) time sync
==> again really really slow

this test doesn't have to do with bad attributes layout, correct ? (since all permissions / attributes are preserved)




other test:

compile 2 kernels & tar bzip2 the directories

then delete the directories & time sync


afterwards extract the kernels-tarballs (with binary-stuff included) and time sync

that'll take pretty long !
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Dont Panic
Guru
Guru


Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.

PostPosted: Thu Jan 28, 2010 5:57 pm    Post subject: Reply with quote

cheater1034 wrote:
ignore most of the phoronix benchmarks too as they are flat out poorly done or irrelevant - how did they come up with the conclusion that ext3 is the fastest FS in the kernel? We dicussed it in IRC already so you should have been there if you want me to explain what's wrong with them :P

I read that Phoronix FS benchmark article. I don't suppose you keep an archive anywhere of your IRC discussions. I'm curious to know what they did that made ext3 look so appealing.

To be honest, after reading that article, I was considering favoring ext3 over ext4 in the future (in those cases where I want a rock-solid, no frills FS).
Back to top
View user's profile Send private message
dusanc
Apprentice
Apprentice


Joined: 19 Sep 2005
Posts: 248
Location: Serbia

PostPosted: Thu Jan 28, 2010 6:27 pm    Post subject: Reply with quote

kernelOfTruth wrote:
do the same test without chown -R portage:portage

basically:

1)
*) extracting the portage-tarball
*) syncing the portage tree
*) time sync

-> rather fast the first time

2)
*) sync the portage tree again
*) time sync
==> again really really slow

this test doesn't have to do with bad attributes layout, correct ? (since all permissions / attributes are preserved)

other test:

compile 2 kernels & tar bzip2 the directories

then delete the directories & time sync

afterwards extract the kernels-tarballs (with binary-stuff included) and time sync

that'll take pretty long !

Can't reproduce first one on R4+CC, now trying second test, making allyesconfig so it's reproducible and large :)

Thanks KoT :)
_________________
Reiser4 Gentoo FAQ [25Dec2016]
Back to top
View user's profile Send private message
cheater1034
Veteran
Veteran


Joined: 09 Sep 2004
Posts: 1558

PostPosted: Thu Jan 28, 2010 8:16 pm    Post subject: Reply with quote

Dont Panic wrote:
cheater1034 wrote:
There is an EXTREMELY rare chance that you would lose all of your data - by extremely rare - i mean 1-5% at the most

8O :o <cough><cough> ROFL

I would hope your chances are better than 1-5%.

I didn't necessarily mean all of your data, the point is - backup your stuff if you want to go experimental - or don't put precious data on it. There are no open regressions for btrfs right now that involve data loss, there could certainly be some regression with that, but considering there is none known at the time - it would be an extremely rare chance.

Quote:
But it's an interesting time for FS selection right now. Reiser4 is MIA. Reiser3 is, well, Reiser3. Btrfs is experimental. And Ext4 has all this talk of performance regressions.

It's a really good time to review your data backup strategies. :)


Reiser3 is OK, reiser4 is somewhat OK (but of course the poor fsync performance, so some of us believe). JFS is a dead duck, XFS is blech, tux3 is a dead duck. Theres an extremely rare chance that you'll find ZFS changing to the GPL license enabling it to become linux compatible, but I doubt it - btrfs will replace it.

btrfs is the best performer, but most people shouldn't make the choice to use an experimental file system for recreational purposes.

Ext4 really screwed be up because of data=writeback being default, which threw me way off when I kept losing data. And they say writeback is the fastest - but it can get awfully slow for me.

So your chance of losing data with default mount options on ext4 is significantly higher than on btrfs :P (data=ordered should be fine)

I think it's a poor time to choice a linux filesystem, because the good stuff that suits all purposes is still experimental :P , and the most widely used ext2/3/4 are not good performers.
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land.
Back to top
View user's profile Send private message
cheater1034
Veteran
Veteran


Joined: 09 Sep 2004
Posts: 1558

PostPosted: Thu Jan 28, 2010 8:26 pm    Post subject: Reply with quote

dusanc wrote:

Can't reproduce first one on R4+CC, now trying second test, making allyesconfig so it's reproducible and large :)

Thanks KoT :)

If you search the issue on google, you'll find a little bit more information on the issue, from 2-3 years ago when it was more actively discussed, but the same problems described still exist and have not been fixed yet.

Dont Panic wrote:
To be honest, after reading that article, I was considering favoring ext3 over ext4 in the future (in those cases where I want a rock-solid, no frills FS).


I think it was the 2.6.31 or 2.6.32 article that they were testing it on. Some tests were simply irrelevant or didn't represent a real situation, other tests they had were not accurate representations due to certain FS behaviors in the situation.

I don't know where the article is now, or I don't have irc logs (maybe someone else does, but not me) I wouldn't say that ext3 or ext4 are great performers, make sure to turn off writeback mode on ext4 as it's the default option and causes potential data loss (it happened to be on several occasions with 2.6.32). I think there's been some general dissatisfaction with ext4 almost right from the beginning for whatever reasons, it didn't turn out to be what most people wanted, which may or may not be something like zfs or btrfs.
_________________
IRC!: #zen-sources on irc.rizon.net
zen-kernel.org
--
Lost in android development land.
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jan 28, 2010 10:25 pm    Post subject: Reply with quote

dusanc wrote:

Can't reproduce first one on R4+CC, now trying second test, making allyesconfig so it's reproducible and large :)

Thanks KoT :)


you're welcome dusanc :)


currently reiser4 is in a pitiful (== broken) state this can be checked by

*) emerging openoffice on an partition that serves as /var/tmp/portage

*) copying over large amounts of data (ideally: your /home partition ;) ) to a big partition formatted with reiser4


in both cases this will lead to BUG messages and the current running system/kernel unable to sync data (somewhat in general to all dics and specifically to the partition with reiser4)

in that case you can do an Emergency Sync via Magic SysRQ Key which will hopefully sync the data in cache to the other partitions but the data in cache of the reiser4-partition is lost (cleverly in NO case so far this lead to data loss or corruption of the existing data on the reiser4-partition so in this regard it also has advantages over the other filesystems :wink: )


@cheater1034:

I haven't noticed any data when using ext4 with data=writeback but I was only using it for a short time that way now it's mounted with barrier=1,data=journal

afaik ext3 had that performance advantage because its default was data=writeback and ext4's default was data=ordered or even journal (I don't know exactly) - anyways the default were in favor of ext3 but data-safety wise it was a nightmare (using ext3) ;)


ext4 in 2.6.32 got some nice improvements regarding performance / throughput: according to a commit (don't know the exact number or title anymore) write-throughput with barrier was improved by 50% !

so anyone using ext4 with barrier should at least update to 2.6.32.* to get some decent performance (and when using the latest patch-level 2.6.32.6 several fixes)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Kollin
Veteran
Veteran


Joined: 25 Feb 2006
Posts: 1137
Location: Sofia/Bulgaria

PostPosted: Thu Jan 28, 2010 10:46 pm    Post subject: Reply with quote

kernelOfTruth wrote:


currently reiser4 is in a pitiful (== broken) state this can be checked by

*) emerging openoffice on an partition that serves as /var/tmp/portage

*) copying over large amounts of data (ideally: your /home partition ;) ) to a big partition formatted with reiser4




+ deleting a big file (7G) takes 5 minutes and during this time ones system is NOT responsive!
Ext4 (even with 2.6.31) behaves a lot better!
_________________
"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..."
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jan 28, 2010 11:31 pm    Post subject: Reply with quote

Kollin wrote:
kernelOfTruth wrote:


currently reiser4 is in a pitiful (== broken) state this can be checked by

*) emerging openoffice on an partition that serves as /var/tmp/portage

*) copying over large amounts of data (ideally: your /home partition ;) ) to a big partition formatted with reiser4




+ deleting a big file (7G) takes 5 minutes and during this time ones system is NOT responsive!
Ext4 (even with 2.6.31) behaves a lot better!


++

I completely forgot that part :oops:

yeah normally it stays quite responsive and transparently deletes it in the background (see above) without being a I/O or CPU-hog
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
dusanc
Apprentice
Apprentice


Joined: 19 Sep 2005
Posts: 248
Location: Serbia

PostPosted: Fri Jan 29, 2010 6:19 am    Post subject: Reply with quote

kernelOfTruth wrote:
...
currently reiser4 is in a pitiful (== broken) state this can be checked by

*) emerging openoffice on an partition that serves as /var/tmp/portage

*) copying over large amounts of data (ideally: your /home partition ;) ) to a big partition formatted with reiser4

in both cases this will lead to BUG messages and the current running system/kernel unable to sync data (somewhat in general to all dics and specifically to the partition with reiser4)...

There was a patch in -mm that did that, it broke sync, andrew took it without ack from Ed, I can't reproduce it with R4+cc for 2.6.31 from kernel.org, or am I wrong?
If I am wrong please can U give me some more data about kernel and mount options that did that?

Thanks :)

PS. Yeah delete times are high, but I haven't managed to make it unresponsive yet. Gonna have to benchmark it a little :)
_________________
Reiser4 Gentoo FAQ [25Dec2016]
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6108
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Fri Jan 29, 2010 10:30 pm    Post subject: Reply with quote

the mount options were

either:

*) noatime
*) noatime,tree.cbk_cache.nr_slots=48,dont_load_bitmap
*) noatime,flush.scan_maxnodes=3000

I haven't used reiser4 for some time now (afaik the last time was with 2.6.32-zen*) - 2.6.31-zen* seemed to work somewhat ok, 2.6.32 was (obviously, like Edward stated) broken



@cheater, dodo, waninkoko:

could one of you guys please bump the upstream zen-kernel sources to 2.6.32-rc6-zen* during the weekend?

it has several fixes for btrfs and the needed mount -o compress-force option (this will hopefully save me and other users several gigabytes ^^) and other nice fixes


many thanks in advance
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
lordcris
Apprentice
Apprentice


Joined: 09 Jul 2002
Posts: 248

PostPosted: Sun Jan 31, 2010 12:06 pm    Post subject: Reply with quote

hello,
i've noticed ureadahead was included in the last release of zen sources ( Linux Kernel v2.6.32-zen6 "Forever and never" ).
How do i enable it?
Do i need a some kind daemon ot load it at startup?
thanks
Back to top
View user's profile Send private message
albright
Advocate
Advocate


Joined: 16 Nov 2003
Posts: 2542
Location: Near Toronto

PostPosted: Sun Jan 31, 2010 4:45 pm    Post subject: Reply with quote

Quote:
i've noticed ureadahead was included in the last release of zen sources ( Linux Kernel v2.6.32-zen6 "Forever and never" ).
How do i enable it?
Do i need a some kind daemon ot load it at startup?


I would like to know the answer to these questions as well - there is no
ureadahead ebuild at the moment it seems
_________________
.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies.    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3 ... 11, 12, 13, 14  Next
Page 12 of 14

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum