| View previous topic :: View next topic |
| Author |
Message |
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
 Posted: Thu Jan 28, 2010 4:10 am Post subject: |
 |
|
| 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  )
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
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 |
|
 |
Twenynge
n00b
Joined: 08 Jan 2010
Posts: 56
|
| Posted: Thu Jan 28, 2010 4:51 am Post subject: Compiled Zen Kernel, Nvidia won't Load |
|
|
| 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 |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
|
| Back to top |
|
|
Twenynge
n00b
Joined: 08 Jan 2010
Posts: 56
|
| Posted: Thu Jan 28, 2010 5:40 am Post subject: |
|
|
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 |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Thu Jan 28, 2010 5:41 am Post subject: |
|
|
| 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 |
  <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 |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Thu Jan 28, 2010 6:05 am Post subject: |
|
|
| Twenynge wrote: |
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 |
|
|
erpalma
n00b
Joined: 19 Feb 2008
Posts: 17
|
| Posted: Thu Jan 28, 2010 10:32 am Post subject: |
|
|
| 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
|
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 |
|
|
dodo1122
Guru
Joined: 02 Sep 2006
Posts: 347
Location: York, England
|
| Posted: Thu Jan 28, 2010 12:25 pm Post subject: |
|
|
| 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!
| 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 |
|
|
erpalma
n00b
Joined: 19 Feb 2008
Posts: 17
|
| Posted: Thu Jan 28, 2010 12:59 pm Post subject: |
|
|
| 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 |
|
|
dusanc
Apprentice
Joined: 19 Sep 2005
Posts: 248
Location: Serbia
|
| Posted: Thu Jan 28, 2010 4:02 pm Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Jan 28, 2010 4:46 pm Post subject: |
|
|
| 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*** 
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  |
|
| Back to top |
|
|
Saundersx
Apprentice
Joined: 11 Apr 2005
Posts: 290
|
| Posted: Thu Jan 28, 2010 5:17 pm Post subject: |
|
|
| 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 )
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
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 |
|
| Back to top |
|
|
dusanc
Apprentice
Joined: 19 Sep 2005
Posts: 248
Location: Serbia
|
| Posted: Thu Jan 28, 2010 5:35 pm Post subject: |
|
|
| 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***
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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Jan 28, 2010 5:48 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Dont Panic
Guru
Joined: 20 Jun 2007
Posts: 322
Location: SouthEast U.S.A.
|
| Posted: Thu Jan 28, 2010 5:57 pm Post subject: |
|
|
| 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 |
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 |
|
|
dusanc
Apprentice
Joined: 19 Sep 2005
Posts: 248
Location: Serbia
|
| Posted: Thu Jan 28, 2010 6:27 pm Post subject: |
|
|
| 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 |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Thu Jan 28, 2010 8:16 pm Post subject: |
|
|
| 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 |
<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 (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 , 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 |
|
|
cheater1034
Veteran
Joined: 09 Sep 2004
Posts: 1558
|
| Posted: Thu Jan 28, 2010 8:26 pm Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Jan 28, 2010 10:25 pm Post subject: |
|
|
| 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 )
@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 |
|
| Back to top |
|
|
Kollin
Veteran
Joined: 25 Feb 2006
Posts: 1139
Location: Sofia/Bulgaria
|
| Posted: Thu Jan 28, 2010 10:46 pm Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Thu Jan 28, 2010 11:31 pm Post subject: |
|
|
| 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 
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 |
|
| Back to top |
|
|
dusanc
Apprentice
Joined: 19 Sep 2005
Posts: 248
Location: Serbia
|
| Posted: Fri Jan 29, 2010 6:19 am Post subject: |
|
|
| 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 |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Fri Jan 29, 2010 10:30 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
lordcris
Apprentice
Joined: 09 Jul 2002
Posts: 248
|
| Posted: Sun Jan 31, 2010 12:06 pm Post subject: |
|
|
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 |
|
|
albright
Advocate
Joined: 16 Nov 2003
Posts: 2588
Location: Near Toronto
|
| Posted: Sun Jan 31, 2010 4:45 pm Post subject: |
|
|
| 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 |
|
|
|
|
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
|
|
Unsupported Software
