Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Official thread: "zen-sources" - Part 6
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 16, 17, 18  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
broch
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jul 2005
Posts: 94

PostPosted: Tue Mar 31, 2009 12:31 pm    Post subject: Reply with quote

I have problem with suspend too:
2.6.29-zen will not wake up from suspend-to-RAM, requires hard reset
2.6.29 vanilla works
nvidia driver 180.37
Back to top
View user's profile Send private message
Phlogiston
Veteran
Veteran


Joined: 27 Jan 2004
Posts: 1925
Location: Europe, Swizerland

PostPosted: Tue Mar 31, 2009 12:54 pm    Post subject: Reply with quote

manwe_ wrote:
Same problem here, system doesn't wake up - black screen, no response on keyboard (even sysrq) or through network. Everything in the newest versions: zen-2.6.29-r1, xorg-server-1.5.3-r5, nvidia-drivers-180.41 and according to post by this guy ( http://www.nvnews.net/vbulletin/showthread.php?t=130796 ) problem is not nvidia-related.


Yes I would agree that this problem is just kernel related :?
_________________
Workstation: 5.1 SurroundSound, LIRC remote control; Laptop [IBM-T43]: patched sources, s2disk/ram, fingerprint sensor
Back to top
View user's profile Send private message
charlie
n00b
n00b


Joined: 21 Oct 2007
Posts: 36

PostPosted: Thu Apr 02, 2009 7:29 am    Post subject: Reply with quote

A week or two ago there were 5-6 power outages at my place whille my computer was working and because of reiser4 I did not lose any data, have corrupt data and did not have to reinstall my OS. Thanks Zen-Sources.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Thu Apr 02, 2009 8:37 pm    Post subject: Reply with quote

Using zen-sources 2.6.29-rc7-zen1 I had my server hard lock on just regular network traffic going about 10 Mbps and I was going on 6 days of uptime without any problems. Thanks to a modern FS, I had to restore from a backup due to fatal corruption on my root partition. I figured the official 2.6.29 release of the zen-sourecs wouldn't cause me any problems given most quirks like this would've been worked out after 1 release candidate and then a final. About 30 minutes after I went to sleep it hard locked again. Even though I was doing video encoding, my sensors showed temps under 45C from my timed out ssh logins.

After two days of being back on reiser4 patched gentoo-sources, even though it's 2.6.28, I'm still running fine with even heavier work on video encoding. I've had 40+ days of uptime with this kernel before :? . Sorry, but zen-sources are too unstable for my tastes. I much wanted to really test out BFQ against CFQ since I go through a good 80GB a week between HDDs and network traffic due to regular HD TV recording and encoding.
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
rmh3093
Advocate
Advocate


Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY

PostPosted: Thu Apr 02, 2009 10:07 pm    Post subject: Reply with quote

DigitalCorpus wrote:
Sorry, but zen-sources are too unstable for my tastes.


WTF?? "Zen-Sources" is no more or less stable/unstable than a vanilla kernel. We dont modify anything that should cause stability issues. I mean, yes we do include developmental filesystems, but no one said you had to use them. And if you do use them, you are using them at your own risk. If you have an issue, its not the fault of "Zen-Sources" its yours!!! Or, its the real kernel developers fault for introducing a bug... which is out of our control. If you want stability, then use the tried and true options, like ext3 and CFQ/Anticipatory IO schedulers. Also comparing reiser4 on .28 to reiser4 on .29 is not a fair comparison. Please pick sane kernel options before you go blaming us for your misfortunes!
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
Back to top
View user's profile Send private message
mroconnor
Guru
Guru


Joined: 24 Feb 2006
Posts: 402
Location: USA

PostPosted: Thu Apr 02, 2009 10:33 pm    Post subject: Reply with quote

i have to agree. Even vanilla can have stability issues w/ less then sane options or experimental file systems. Unfair to blame Zen Sources.
Back to top
View user's profile Send private message
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Thu Apr 02, 2009 11:19 pm    Post subject: Reply with quote

I use the same options for by of my kernels and my system configuration hasn't changed. I've had two failures with normal use and the other I haven't had a problem with. Options have been the same on both and I'd be happy to know why my system crash under zen and not under gentoo-sources when I haven't changed anything, sans BFQ instead of CFQ. The problems I have had with reiser4 I'm not blaming on zen because I have had them before under power failures and the like. I'm sorry my post reads that way.

I only moved from zen because of the 2 hard locks that I had within 12 hours under the same usage patterns I'm doing now.

From what I've read this still falls under the bounds of sane for CFLAGS, which I've compiled both kernels with:
Code:
-march=native -O2 -pipe -mno-push-args -mcx16 -msahf

I've been using this for LDFLAGS:
Code:
-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,now -Wl,--hash-style=gnu

Now, I am running an overclocked Q6700, but after 9 months of testing settings and tweaking, I've settled on 400MT/s FSB w/ 8x multiplier and 8GB of DDR2 800MHz. Never have had a problem with stability and even though hindsight shows a Q6600 would've done just as well with the sample I got, I would've spent the same on either when I bought it.
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
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 Apr 03, 2009 9:53 am    Post subject: Reply with quote

DigitalCorpus wrote:

I've been using this for LDFLAGS:
Code:
-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,now -Wl,--hash-style=gnu



I believe cheater will LOVE you for those ldflags :P
_________________
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
cheater1034
Veteran
Veteran


Joined: 09 Sep 2004
Posts: 1558

PostPosted: Sat Apr 04, 2009 5:40 pm    Post subject: Reply with quote

DigitalCorpus wrote:
I use the same options for by of my kernels and my system configuration hasn't changed. I've had two failures with normal use and the other I haven't had a problem with. Options have been the same on both and I'd be happy to know why my system crash under zen and not under gentoo-sources when I haven't changed anything, sans BFQ instead of CFQ. The problems I have had with reiser4 I'm not blaming on zen because I have had them before under power failures and the like. I'm sorry my post reads that way.


1) Gentoo-sources is 2.6.28, the zen you used was 2.6.29+, lots have changed and a bug VERY easily could have been introduced since then.
2) Reiser4 is not a stable filesystem, probably the least-stable filesystem in zen-sources (just because it has design flaws and bugs that have been around since the beginning)
3) You changed to BFQ, you obviously never realized that there could very easily be bugs in BFQ? It is not at the point of approval for linux-next and definitely not linus' tree, there are bound to be bugs.

Of course, it would be a lot easier to exclude bfq if you would have thought to not use it? Because an unofficial, unsupported, buggy i/o scheduler is a pretty big change compared to cfq... Reiser4 never behaved well with cfq anyway, bfq probably exposes the worst of reiser4.

Anyway, use a filesystem that doesn't have 3 year old problems in the code: ext4, btrfs (experimental, but has been more stable than any of my reiser4's have ever been and i get zlib compression), xfs, etc.

Quote:
I only moved from zen because of the 2 hard locks that I had within 12 hours under the same usage patterns I'm doing now.

I don't care if you use zen or not, but I'm definitely entitled to make fun of you if you didn't ever consider that bfq or reiser4 could be broken, as I believe it is in reiser4's nature and bfq has not had an update since a year ago and bugs were revealed that have not been fixed to this date.

Also, there is a bug tracker on the zen-sources site, and forums. Using them wouldn't be a bad idea to report a problem because I don't check on here ever anymore.

Quote:
From what I've read this still falls under the bounds of sane for CFLAGS, which I've compiled both kernels with:
Code:
-march=native -O2 -pipe -mno-push-args -mcx16 -msahf

I've been using this for LDFLAGS:
Code:
-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,now -Wl,--hash-style=gnu

Now, I am running an overclocked Q6700, but after 9 months of testing settings and tweaking, I've settled on 400MT/s FSB w/ 8x multiplier and 8GB of DDR2 800MHz. Never have had a problem with stability and even though hindsight shows a Q6600 would've done just as well with the sample I got, I would've spent the same on either when I bought it.


I'm going to assume you think that the kernel builds with the gcc parameters found in make.conf? Because if you think that, you're wrong.

Anyway:
1) Custom cflags is an option in the zen-sources Kconfig, but you should never use it for a kernel build
2) -march=native compile is an option in the zen-sources Kconfig, but I reccomend against using it for a kernel build
3) You are not allowed to set LDFLAGS in the zen-sources Kconfig, you'd have to edit the Makefile

Elaboration:
1) Why set any cflag parameters? There are defaults for a reason. And there is an option for an -Os build, which is all I'd do if you wanted a smaller kernel. Use kernel defaults for cflags, unless you want to create a bigger image that isn't faster in the slightest and may create problems for some of the modules you use.
2) It should be harmless, but I don't think you need to set a march in the kernel compile, native doesn't behave perfectly with everything anyway, but no march setting or the default march setting would apply the same as custom cflags.
3) The kernel doesn't link against anything...
_________________
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
DigitalCorpus
Apprentice
Apprentice


Joined: 30 Jul 2007
Posts: 245

PostPosted: Sat Apr 04, 2009 8:38 pm    Post subject: Reply with quote

cheater1034 wrote:
DigitalCorpus wrote:
I use the same options for by of my kernels and my system configuration hasn't changed. I've had two failures with normal use and the other I haven't had a problem with. Options have been the same on both and I'd be happy to know why my system crash under zen and not under gentoo-sources when I haven't changed anything, sans BFQ instead of CFQ. The problems I have had with reiser4 I'm not blaming on zen because I have had them before under power failures and the like. I'm sorry my post reads that way.


1) Gentoo-sources is 2.6.28, the zen you used was 2.6.29+, lots have changed and a bug VERY easily could have been introduced since then.
2) Reiser4 is not a stable filesystem, probably the least-stable filesystem in zen-sources (just because it has design flaws and bugs that have been around since the beginning)
3) You changed to BFQ, you obviously never realized that there could very easily be bugs in BFQ? It is not at the point of approval for linux-next and definitely not linus' tree, there are bound to be bugs.

I've never ever had a crash that was caused by Reiser4. From all I've read, btrfs would be more unstable since they've said they haven't exactly settled on a disk format. That may have changed last I went to their site though.

Quote:
Of course, it would be a lot easier to exclude bfq if you would have thought to not use it? Because an unofficial, unsupported, buggy i/o scheduler is a pretty big change compared to cfq... Reiser4 never behaved well with cfq anyway, bfq probably exposes the worst of reiser4.

Anyway, use a filesystem that doesn't have 3 year old problems in the code: ext4, btrfs (experimental, but has been more stable than any of my reiser4's have ever been and i get zlib compression), xfs, etc.

CFQ actually behaves the best with Reiser4 from my trivial experience and that is backed by more knowledgeable users such as kernelOftruth. The transfers that were taking place were exclusively on my XFS partitions. Also file contents of what was being read were cached in RAM for the first crash so no I/O scheduler should've been responsible. My usage with Reiser4 and well as other FS's is very much a ymmv and this is proof by the extensive and locked flame wars, I mean threads, in this forum for a small example.

Quote:
Quote:
I only moved from zen because of the 2 hard locks that I had within 12 hours under the same usage patterns I'm doing now.

I don't care if you use zen or not, but I'm definitely entitled to make fun of you if you didn't ever consider that bfq or reiser4 could be broken, as I believe it is in reiser4's nature and bfq has not had an update since a year ago and bugs were revealed that have not been fixed to this date.

Also, there is a bug tracker on the zen-sources site, and forums. Using them wouldn't be a bad idea to report a problem because I don't check on here ever anymore.

That is the most pompous, snide and arrogant thing that I've read on this forum. Please behave professionally if you wish to actually provide help with currently unsolvable problems. The Gentoo community is known for frequent infighting, and propagating this behavior certainty isn't constructive. I would have posted a bug report, but if you re-read my post I don't mention anything about a kernel oops. Now that may be my bad, but if I remember correctly a hard lock is when the system becomes explicitly unresponsive and nothing even from the kernel is even printed on screen. On the other hand a kernel panic/oops will conveniently print a trace out on your screen. I had 2 hard locks under different circumstances. I was given no information from my system about what exactly happened and as I mentioned this is a server, though I do run experimental software which is against the sever paradigm, I would much like to keep this up and running. In order to find the bug to report, I'd have to be bouncing back and forth between liveCDs and random testing to find out why normal circumstances hard locked my system.

If there is an error in my logic, please point it out and do so professionally.

Quote:
Quote:
From what I've read this still falls under the bounds of sane for CFLAGS, which I've compiled both kernels with:
Code:
-march=native -O2 -pipe -mno-push-args -mcx16 -msahf

I've been using this for LDFLAGS:
Code:
-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,now -Wl,--hash-style=gnu

Now, I am running an overclocked Q6700, but after 9 months of testing settings and tweaking, I've settled on 400MT/s FSB w/ 8x multiplier and 8GB of DDR2 800MHz. Never have had a problem with stability and even though hindsight shows a Q6600 would've done just as well with the sample I got, I would've spent the same on either when I bought it.


I'm going to assume you think that the kernel builds with the gcc parameters found in make.conf? Because if you think that, you're wrong.

Anyway:
1) Custom cflags is an option in the zen-sources Kconfig, but you should never use it for a kernel build
2) -march=native compile is an option in the zen-sources Kconfig, but I reccomend against using it for a kernel build
3) You are not allowed to set LDFLAGS in the zen-sources Kconfig, you'd have to edit the Makefile

Elaboration:
1) Why set any cflag parameters? There are defaults for a reason. And there is an option for an -Os build, which is all I'd do if you wanted a smaller kernel. Use kernel defaults for cflags, unless you want to create a bigger image that isn't faster in the slightest and may create problems for some of the modules you use.
2) It should be harmless, but I don't think you need to set a march in the kernel compile, native doesn't behave perfectly with everything anyway, but no march setting or the default march setting would apply the same as custom cflags.
3) The kernel doesn't link against anything...

You should know that it is a bad idea to assume. I know that the kernel does no build with the parameters from /etc/make.conf. I manually edited my 2.6.28 Makefile and tested my CFLAGS for 2 months without a single crash or problems induced by them. I never set LDFLAGS in my kernel.

Just because it is smaller doesn't mean it is faster. Now it may be quicker, i.e. less latency, but that may be at the expense of throughput. I don't know how to test the kernel for for real world, but I'm perfectly fine with my 1890kB kernel file size. I do understand the concept of smaller code is easier to cache, but I have yet to see any real world benchmarks that the smaller more cache-friendly code is faster that the larger more optimized code. Your statement flies blindly in the face of what GCC's documentation says about the use of -O2. Also I'm on a Q6700. I have 2x4MiB of L2 cache right and 128K data and executable L1 cache? my kernel is under 2MiB right? What do I have to loose? I have 1497 executables in /usr/bin totaling 133MB (avg of 87KB per binary), 178 in /usr/sbin @ 15MB (avg 82KB). Now mencoder (my functional heavy lifter) is just over 8MiB, but I'm actively in approx. 30 hours of encoding right now and I'm collecting time statistic too so I don't really want to mess that up.


Unless your reply is outside of assuming that I know absolutely nothing or deciding to make any of comments about things other than facts, I will not engage in a personalized fight with you. I deal with supervising over 200 people over the corse of a work week and in order for anything meaningful to come out of this conversation, I would need my system to actually tell me about what went wrong. Other than that, anything else brought up is pure conjecture as to the possible causes for the hard locks. This is a Linux distribution. There are a few hundred of them right? Your milage will vary within distribution and within what kernel you decide to use. Mine wasn't very far and I really wish it would've been farther
_________________
Atlas (HDTV PVR, HTTP & Media server)
http://atlas.selfip.net/Info/
Back to top
View user's profile Send private message
cheater1034
Veteran
Veteran


Joined: 09 Sep 2004
Posts: 1558

PostPosted: Sat Apr 04, 2009 9:06 pm    Post subject: Reply with quote

DigitalCorpus wrote:
...


Perhaps the reiser4 at the time I got it from mmotm was bad? I'll try the normal reiser4 patch (http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/reiser4-for-2.6/reiser4-for-2.6.29.patch.bz2) and see what possible could have changed that went wrong (if anything) from mmotm to this patch (I pulled the reiser4 from mmotm a little while ago so there could have easily been a bug then that there isn't now)

When I'm done with that i'll let you know and you could try pulling and go again (or try 2.6.29.1 with the patch above and see if you get the same behavior, since if it isn't reiser4 or bfq i'd imagine you'd get the same thing with the upstream kernel)

Also, btrfs' disk format isn't subject to re-format required changes anymore, any disk format changes will just need the matching progs, no re-format or anything.

And I'd check dmesg when you're making your transfers, maybe you'll see kernel bugs or warnings in there that'll lead to the problem.

I'm not professional either, so I don't act like one. I just like to get information instead of "zen-sources is too unstable for my tastes" when there's a problem. Typically, you'd get better help in #zen-sources because I don't do good at helping problems unless it's live.

And from listing your LDFLAGS i guessed you were building your kernel with them, and your cflags can be changed in the Kconfig in zen (See custom-cflags branch), so you don't need to change the makefile every time.
_________________
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
rmh3093
Advocate
Advocate


Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY

PostPosted: Sun Apr 05, 2009 4:11 am    Post subject: Reply with quote

cheater1034 wrote:
DigitalCorpus wrote:
...


Perhaps the reiser4 at the time I got it from mmotm was bad? I'll try the normal reiser4 patch (http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/reiser4-for-2.6/reiser4-for-2.6.29.patch.bz2) and see what possible could have changed that went wrong (if anything) from mmotm to this patch (I pulled the reiser4 from mmotm a little while ago so there could have easily been a bug then that there isn't now)

When I'm done with that i'll let you know and you could try pulling and go again (or try 2.6.29.1 with the patch above and see if you get the same behavior, since if it isn't reiser4 or bfq i'd imagine you'd get the same thing with the upstream kernel)

Also, btrfs' disk format isn't subject to re-format required changes anymore, any disk format changes will just need the matching progs, no re-format or anything.

And I'd check dmesg when you're making your transfers, maybe you'll see kernel bugs or warnings in there that'll lead to the problem.

I'm not professional either, so I don't act like one. I just like to get information instead of "zen-sources is too unstable for my tastes" when there's a problem. Typically, you'd get better help in #zen-sources because I don't do good at helping problems unless it's live.

And from listing your LDFLAGS i guessed you were building your kernel with them, and your cflags can be changed in the Kconfig in zen (See custom-cflags branch), so you don't need to change the makefile every time.


just use Btrfs! reiser4 sucks
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
Back to top
View user's profile Send private message
yngwin
Retired Dev
Retired Dev


Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China

PostPosted: Sun Apr 05, 2009 7:51 am    Post subject: Reply with quote

rmh3093 wrote:
just use Btrfs! reiser4 sucks

You forgot the sarcasm tag or something. :wink:
Reiser4 is the most stable filesystem in my experience and has been around for years. Don't let people's bad experiences with Reiser4 in its pre-1.0 days give you the wrong impression.

Now btrfs is a new filesystem, which is still experimental and unstable. You should be able to draw your own conclusions from that...

But, like always, YMMV. 8)
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF
Back to top
View user's profile Send private message
Zoboulo
Tux's lil' helper
Tux's lil' helper


Joined: 07 Apr 2007
Posts: 97

PostPosted: Sun Apr 05, 2009 10:48 am    Post subject: Reply with quote

broch wrote:
I have problem with suspend too:
2.6.29-zen will not wake up from suspend-to-RAM, requires hard reset
2.6.29 vanilla works
nvidia driver 180.37


Hi,
Is this probleme corrected ?
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: Sun Apr 05, 2009 12:40 pm    Post subject: Reply with quote

yngwin wrote:
rmh3093 wrote:
just use Btrfs! reiser4 sucks

You forgot the sarcasm tag or something. :wink:
Reiser4 is the most stable filesystem in my experience and has been around for years. Don't let people's bad experiences with Reiser4 in its pre-1.0 days give you the wrong impression.

Now btrfs is a new filesystem, which is still experimental and unstable. You should be able to draw your own conclusions from that...

But, like always, YMMV. 8)


++

:)

the most problems with reiser4 are due to the fact that it's not included in linus' tree and therefore can't keep up with all the latest changes
_________________
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
ponciarello
Apprentice
Apprentice


Joined: 22 Jul 2008
Posts: 223
Location: beach of slack

PostPosted: Sun Apr 05, 2009 2:14 pm    Post subject: Reply with quote

Zoboulo wrote:
broch wrote:
I have problem with suspend too:
2.6.29-zen will not wake up from suspend-to-RAM, requires hard reset
2.6.29 vanilla works
nvidia driver 180.37


Hi,
Is this probleme corrected ?

looking at git commits I think yes, but trying is the best way to be sure :D

you have to checkout git master (-zen3), no patches yet.

surely won't be done with tuxonice.
_________________
look for monty python channel on youtube :D
Back to top
View user's profile Send private message
rmh3093
Advocate
Advocate


Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY

PostPosted: Sun Apr 05, 2009 7:06 pm    Post subject: Reply with quote

kernelOfTruth wrote:
yngwin wrote:
rmh3093 wrote:
just use Btrfs! reiser4 sucks

You forgot the sarcasm tag or something. :wink:
Reiser4 is the most stable filesystem in my experience and has been around for years. Don't let people's bad experiences with Reiser4 in its pre-1.0 days give you the wrong impression.

Now btrfs is a new filesystem, which is still experimental and unstable. You should be able to draw your own conclusions from that...

But, like always, YMMV. 8)


++

:)

the most problems with reiser4 are due to the fact that it's not included in linus' tree and therefore can't keep up with all the latest changes


no I didnt forget any sarcasm tags, while I am NOT saying Btrfs is stable its probably no more unstable than reiser4, it does have active developers which you can talk to in #btrfs if you do experience a bug (something u cant get with reiser4), btrfs is included in the vanilla kernel so it will always be up to date with upstream changes (something you dont get with reiser4), to get reiser4 in the latest kernel we usually have to make the changes our self or back port an mm patch (which often means removing junk from mm) both of which are likely to introduce bugs, btrfs supports compression like reiser4, btrfs has support for ssd's. btrfs has other goodies, too many to even mention

i've been running btrfs 0.18 on my x86_64 box for months with out any issues (as my rootfs also)... i've recently installed it on my laptop's rootfs and I did some hardpower offs while massive disk IO and nothing got trashed

so with all that being said, i stand by my opinion that reiser4 sucks (with out sarcasm), you reiser4 users need to start using a filesystem with a future!
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
Back to top
View user's profile Send private message
CooSee
Guru
Guru


Joined: 20 Nov 2004
Posts: 461
Location: Earth

PostPosted: Sun Apr 05, 2009 7:15 pm    Post subject: Reply with quote

rmh3093 wrote:
kernelOfTruth wrote:
yngwin wrote:
rmh3093 wrote:
just use Btrfs! reiser4 sucks

You forgot the sarcasm tag or something. :wink:
Reiser4 is the most stable filesystem in my experience and has been around for years. Don't let people's bad experiences with Reiser4 in its pre-1.0 days give you the wrong impression.

Now btrfs is a new filesystem, which is still experimental and unstable. You should be able to draw your own conclusions from that...

But, like always, YMMV. 8)


++

:)

the most problems with reiser4 are due to the fact that it's not included in linus' tree and therefore can't keep up with all the latest changes


no I didnt forget any sarcasm tags, while I am NOT saying Btrfs is stable its probably no more unstable than reiser4, it does have active developers which you can talk to in #btrfs if you do experience a bug (something u cant get with reiser4), btrfs is included in the vanilla kernel so it will always be up to date with upstream changes (something you dont get with reiser4), to get reiser4 in the latest kernel we usually have to make the changes our self or back port an mm patch (which often means removing junk from mm) both of which are likely to introduce bugs, btrfs supports compression like reiser4, btrfs has support for ssd's. btrfs has other goodies, too many to even mention

i've been running btrfs 0.18 on my x86_64 box for months with out any issues (as my rootfs also)... i've recently installed it on my laptop's rootfs and I did some hardpower offs while massive disk IO and nothing got trashed

so with all that being said, i stand by my opinion that reiser4 sucks (with out sarcasm), you reiser4 users need to start using a filesystem with a future!



using BTRFS since clean install ( 5 Months ago ), include ' rootfs ', no Problems so far, even with ' hard resets ' :!:

CooSee ' Ya
_________________
beQuiet! Silent Base 800 Black - MSI C236A - Xeon E3-1245v5 - 32GB RAM Kingston - Sapphire Nitro+ Radeon RX590 8G - Samsung PM961 M.2 128GB - Samsung 840 EVO 120GB - Creative Sound Blaster RX PCIe - Logitech Z623 2.1 - G110 Keyboard - Mouse G400
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: Sun Apr 05, 2009 7:46 pm    Post subject: Reply with quote

rmh3093 wrote:


so with all that being said, i stand by my opinion that reiser4 sucks (with out sarcasm), you reiser4 users need to start using a filesystem with a future!


yeah, reiser4 at some points sucks (delete performance, working with big files, some other areas) but those are only minor issues compared to the other filesystems I tested so far (file corruption, zeroing out files during hardlock or power outage, 3 times slower performance, using twice as much space, torturing my harddrives, eating battery life, etc.)

well - so how space efficient is btrfs compared to jfs, reiserfs or reiser4 ?

I've been asking this for months now and nobody could give an definite answer - I don't want to know how efficient it can or will be BUT how efficient it is RIGHT NOW

e.g. space-usage of the exact same portage-tree with lzo-compression reiser4 vs. btrfs

or btrfs vs. jfs or reiserfs

I know people tend to say that space today is pretty cheap (how right you are), unfortunately my harddrives are filling faster than I can buy or effort newer ones :wink:

therefore I need an efficient (== space usage, performance, safety, etc.) filesystem so that I can enjoy my harddrives a little longer
_________________
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
rmh3093
Advocate
Advocate


Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY

PostPosted: Sun Apr 05, 2009 10:41 pm    Post subject: Reply with quote

kernelOfTruth wrote:
rmh3093 wrote:


so with all that being said, i stand by my opinion that reiser4 sucks (with out sarcasm), you reiser4 users need to start using a filesystem with a future!


yeah, reiser4 at some points sucks (delete performance, working with big files, some other areas) but those are only minor issues compared to the other filesystems I tested so far (file corruption, zeroing out files during hardlock or power outage, 3 times slower performance, using twice as much space, torturing my harddrives, eating battery life, etc.)

well - so how space efficient is btrfs compared to jfs, reiserfs or reiser4 ?

I've been asking this for months now and nobody could give an definite answer - I don't want to know how efficient it can or will be BUT how efficient it is RIGHT NOW

e.g. space-usage of the exact same portage-tree with lzo-compression reiser4 vs. btrfs

or btrfs vs. jfs or reiserfs

I know people tend to say that space today is pretty cheap (how right you are), unfortunately my harddrives are filling faster than I can buy or effort newer ones :wink:

therefore I need an efficient (== space usage, performance, safety, etc.) filesystem so that I can enjoy my harddrives a little longer


well idk about space efficiency, I never really compare those types of stats, with hundreds to thousands of gigs of space on harddrives these days does that even matter.... however, i think it would be safe to say btrfs with -o compress would be better than jfs or reiserfs with regards to space
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
Back to top
View user's profile Send private message
tranquilcool
Veteran
Veteran


Joined: 25 Mar 2005
Posts: 1160

PostPosted: Thu Apr 16, 2009 11:36 pm    Post subject: Reply with quote

2.6.30-rc2-zen0 rocks hard.

some reiserfs console messages, i think, from upstream;
REISERFS warning (device sda3): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)

no reiser4, i hope, for now.

for nvidia-drivers 173.14.18 here goes a patch(got it somwhere and modified to suit me)

--- usr/src/nv/nv.c 2009-04-04 08:40:50.000000000 -0700
+++ ../NVIDIA-Linux-x86-173.14.18-pkg0/usr/src/nv/nv.c 2009-04-07 10:32:40.000000000 -0700
@@ -588,9 +588,11 @@
* Set the module owner to ensure that the reference
* count reflects accesses to the proc files.
*/
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
proc_nvidia->owner = THIS_MODULE;
proc_nvidia_cards->owner = THIS_MODULE;
proc_nvidia_warnings->owner = THIS_MODULE;
+#endif

for (j = 0; j < num_nv_devices; j++)
{
@@ -610,8 +612,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_cardinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
if (nvos_find_agp_capability(dev)) {
/*
@@ -624,7 +627,9 @@
goto failed;
}

+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif
proc_nvidia_agp = entry;

entry = create_proc_entry("status", flags, proc_nvidia_agp);
@@ -635,7 +640,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_status;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif

entry = create_proc_entry("host-bridge", flags, proc_nvidia_agp);
if (!entry) {
@@ -645,8 +652,9 @@

entry->data = NULL;
entry->read_proc = nv_kern_read_agpinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
entry = create_proc_entry("card", flags, proc_nvidia_agp);
if (!entry) {
NV_PCI_DEV_PUT(dev);
@@ -655,7 +663,9 @@

entry->data = nv;
entry->read_proc = nv_kern_read_agpinfo;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif
}

NV_PCI_DEV_PUT(dev);
@@ -666,15 +676,17 @@
goto failed;

entry->read_proc = nv_kern_read_version;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
entry = create_proc_entry("registry", flags, proc_nvidia);
if (!entry)
goto failed;

entry->read_proc = nv_kern_read_registry;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
-
+#endif
return;

failed:
@@ -700,7 +712,9 @@

entry->data = (void *)message;
entry->read_proc = nv_kern_read_warning;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 29))
entry->owner = THIS_MODULE;
+#endif /* below 2.6.29 */
#endif
}

after patching edit nv.c lines 631 to 633 by hand 'cos 'am kinda lazy.
edit the file to use any nvidia-drivers version you have because, i think, it works..
_________________
this is a strange strange world.


Last edited by tranquilcool on Fri Apr 17, 2009 12:41 am; edited 1 time in total
Back to top
View user's profile Send private message
rmh3093
Advocate
Advocate


Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY

PostPosted: Thu Apr 16, 2009 11:55 pm    Post subject: Reply with quote

tranquilcool wrote:
2.6.30-rc2-zen0 rocks hard.

some reiserfs console messages, i think, from upstream;
REISERFS warning (device sda3): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)

no reiser4, i hope, for now.



yeah im not done yet
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
Back to top
View user's profile Send private message
chrisyu
Apprentice
Apprentice


Joined: 10 Apr 2003
Posts: 206
Location: China

PostPosted: Fri Apr 17, 2009 3:36 am    Post subject: Reply with quote

Great source, thanks.

Seems one file block/Makefile has some un-needed lines

http://git.zen-sources.org/?p=zen.git;a=blob_plain;f=block/Makefile;hb=HEAD

Have to delete these lines to get make done.


Last edited by chrisyu on Fri Apr 17, 2009 11:57 pm; edited 1 time in total
Back to top
View user's profile Send private message
rahulthewall
Veteran
Veteran


Joined: 01 Nov 2007
Posts: 1264
Location: Zürich

PostPosted: Fri Apr 17, 2009 7:24 am    Post subject: Reply with quote

chrisyu wrote:
Greate source, thanks.

Seems one file block/Makefile has some un-needed lines

http://git.zen-sources.org/?p=zen.git;a=blob_plain;f=block/Makefile;hb=HEAD

Have to delete these lines to get make done.


Thanks for the headup - ran into the same problem - hopefully someone will commit the fix to git.
_________________
Who shall guard the guards?
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 Apr 17, 2009 10:02 am    Post subject: Reply with quote

tranquilcool wrote:
2.6.30-rc2-zen0 rocks hard.

some reiserfs console messages, i think, from upstream;
REISERFS warning (device sda3): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-13)

no reiser4, i hope, for now.



watch out for reiserfs problems !

they're currently removing the BKL (big kernel lock) and doing some optimizations so atm I wouldn't use it if you're having critical data which shouldn't get lost

what do you mean with
Quote:
no reiser4, i hope, for now.
? 8O

update:


hey ! reiser4 is missing ?! :wink:

rmh3093 take your time ...

thanks btw for your continued efforts in maintaining zen, guys :)
_________________
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
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 ... 9, 10, 11 ... 16, 17, 18  Next
Page 10 of 18

 
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