Re: Installing Fedora Core with root on Reiserfs
On Tuesday 19 July 2005 01:59, Jeff Mahoney [EMAIL PROTECTED] wrote: If the root file system is reiserfs then reiserfs.ko will (or at least should) be included in the initrd. Right, but initrd is in /boot which is not something separate: it is on the same reiserfs root partition.. The situation you're describing is one that is well tested by now. If the root filesystem is reiserfs, and /boot is a part of it, reiserfs.ko MUST be in the initrd. Otherwise, there is a chicken/egg problem and the system will not boot. This works in all my tests. The reiserfs.ko module is apparently in the initrd. Also if the original bug concerned a lack of reiserfs.ko in the initrd then re-running GRUB would not fix things. I can't reproduce the bug, it just works for me. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Testimonials page
There actually is an International Standard on this (ISO-31-0), have a look at: http://www.answers.com/topic/iso-31 which states: * Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign. * ISO 31-0 specifies that the decimal sign is the comma on the baseline, but recognizes that in English documents a dot on the line is also commonly used. Christian Iversen [EMAIL PROTECTED] wrote: On Monday 18 July 2005 00:18, Hubert Chan wrote: On Sun, 17 Jul 2005 22:22:32 +0200, Christian Iversen [EMAIL PROTECTED] said: In particular, in French, period is for the thousands separator, and comma is the decimal point. AFAIK it's the same in Sweden, Norway, Denmark, Germany, The Netherlands, and in fact most of Europe. I'm wondering if it's based mostly on region or language. For example, I know that for the English-speaking portion of North America, we use comma for the thousands separator. But for the French-speaking population (e.g. Quebec), or when writing in French, comma is the decimal separator. Do Swedes, Norwegians, etc. use period as the thousands separator even when writing in English? No, that wouldn't make sense :-) I think it's true that it's language-based. To make matters worse though, I've seen some exams with a mixed danish/english contents use both within a few lines of text. And on top of that, it's sometimes reversed because , is used as a logical seperator in many programming langauges. But it's probably safe to say that outside of physics (and even there it would be odd), 123.456 is 1 dot 23456 * 10^5 -- Regards, Christian Iversen Regards Kris Van Bruwaene *** Disclaimer *** Deze e-mail, met eventuele bijlagen, is alleen bestemd voor de persoon of organisatie aan wie hij gericht is en, in voorkomend geval, alleen voor het daarin opgegeven doel of gebruik. Hij kan vertrouwelijke informatie bevatten en/of persoonlijke standpunten die niet noodzakelijk met die van de VRT stroken. Elk gebruik van deze informatie (zoals bewerken, doorsturen, geheel of gedeeltelijk reproduceren of verspreiden in welke vorm ook) door anderen dan de geadresseerde, is verboden. Hebt U deze e-mail per vergissing ontvangen, meld dat dan a.u.b. aan de VRT en wis de e-mail.
Re: Testimonials page
Kris Van Bruwaene wrote: There actually is an International Standard on this (ISO-31-0), have a look at: http://www.answers.com/topic/iso-31 which states: * Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign. * ISO 31-0 specifies that the decimal sign is the comma on the baseline, but recognizes that in English documents a dot on the line is also commonly used. The french have long controlled the ISO standards process. In this case, it is probably a good standard though. Spaces work for my mind
newly created 8.5TB reiserfs fails fsck on amd64 and causes OOPS
This is on a dual-CPU opteron system, with 2 x 3ware 9500 12-channel
SATA controllers for a total of 8.5TB; I've configured a RAID5 over each
3ware controller, and use linux md RAID0 over those two devices.
There was an issue with linux md RAID0 for that size, but that's been
resolved (at least, the problem I had first :-)
The device itself seems to work fine, as reiser4 works. I
wanted to compare to reiserfs 3.6, so I created a reiserfs, mounted it,
and tried to use it. Running bonnie++ on it caused an oops, apparently
in the reiserfs code:
kernel: Unable to handle kernel paging request at 2aad79ea RIP:
kernel: 801b0ac1{scan_bitmap_block+129}
kernel: PGD 954ad067 PUD 9a1af067 PMD b75bc067 PTE 0
kernel: Oops: [1] SMP
kernel: CPU 0
kernel: Modules linked in: raid0 reiser4 zlib_deflate zlib_inflate raid5 raid6
xor ipv6 evdev tg3 3w_9xxx hw_random i2c_amd756 i2c_amd8111 i2c_core psmouse rtc
kernel: Pid: 12006, comm: bonnie++ Not tainted 2.6.12.2.raid0fixreiser4
kernel: RIP: 0010:[scan_bitmap_block+129/768]
801b0ac1{scan_bitmap_block+129}
kernel: RSP: 0018:81007f461a18 EFLAGS: 00010286
kernel: RAX: 2aad79ea RBX: 001c RCX: 21e0
kernel: RDX: RSI: 001c RDI: 81007f461d98
kernel: RBP: c250a1c0 R08: 0001 R09: 0011
kernel: R10: R11: R12: 81007f461a9c
kernel: R13: 21e0 R14: 81007f0ffc00 R15: 0011
kernel: FS: 2b26f8c0() GS:804b7480()
knlGS:
kernel: CS: 0010 DS: ES: CR0: 8005003b
kernel: CR2: 2aad79ea CR3: d9d11000 CR4: 06e0
kernel: Process bonnie++ (pid: 12006, threadinfo 81007f46, task
81007feee0f0)
kernel: Stack: 0010 801cabce 001c0001
81007f461d98
kernel:81009f6c9018 001c 81007f0ffc00
001c
kernel:81007f461d98 0001
kernel: Call Trace:801b10a9{scan_bitmap+585}
801b2313{reiserfs_allocate_blocknrs+803}
kernel:801bc08c{reiserfs_allocate_blocks_for_region+524}
kernel:80178f36{alloc_page_buffers+102}
801ca1a8{pathrelse+40}
kernel:801484b0{autoremove_wake_function+0}
801be315{reiserfs_file_write+1045}
kernel:801655ad{do_anonymous_page+861}
80165b90{handle_mm_fault+304}
kernel:80203dd1{__up_read+33}
8011e289{do_page_fault+601}
kernel:8032a7d3{_spin_lock+3}
80176c90{vfs_write+192}
kernel:80176de3{sys_write+83}
8010d91a{system_call+126}
kernel:
kernel:
kernel: Code: 8b 00 48 c1 e8 02 a8 01 74 17 49 8b 86 70 02 00 00 48 ff 80
kernel: RIP 801b0ac1{scan_bitmap_block+129} RSP 81007f461a18
kernel: CR2: 2aad79ea
I rebooted (hard, as a shutdown didn't work...). After that, I tried a
mkfs followd by an fsck, which gives an error! Here's the console log:
satazilla:~# mkfs.reiserfs /dev/md13
mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
A pair of credits:
Joshua Macdonald wrote the first draft of the transaction manager. Yuri Rupasov
did testing and benchmarking, plus he invented the r5 hash (also used by the
dcache code). Yura Rupasov, Anatoly Pinchuk, Igor Krasheninnikov, Grigory
Zaigralin, Mikhail Gilula, Igor Zagorovsky, Roman Pozlevich, Konstantin
Shvachko, and Joshua MacDonald are former contributors to the project.
The Defense Advanced Research Projects Agency (DARPA, www.darpa.mil) is the
primary sponsor of Reiser4. DARPA does not endorse this project; it merely
sponsors it.
Guessing about desired format.. Kernel 2.6.12.2.raid0fixreiser4 is running.
Format 3.6 with standard journal
Count of blocks on the device: 2148377056
Number of blocks consumed by mkreiserfs formatting process: 8239
Blocksize: 4096
Hash function used to sort names: r5
Journal Size 8193 blocks (first block 18)
Journal Max transaction length 1024
inode generation number: 0
UUID: 10ae60ee-1abb-49d1-ae55-cf238626c0b5
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
ALL DATA WILL BE LOST ON '/dev/md13'!
Continue (y/n):y
Initializing journal - 0%20%40%60%80%100%
Syncing..ok
Tell your friends to use a kernel based on 2.4.18 or later, and especially not a
kernel based on 2.4.9, when you use reiserFS. Have fun.
ReiserFS is successfully created on /dev/md13.
satazilla:~# reiserfsck /dev/md13
reiserfsck 3.6.19 (2003 www.namesys.com)
*
** If you are using the latest reiserfsprogs and it fails **
** please email bug reports to reiserfs-list@namesys.com, **
** providing as much information as possible -- your **
** hardware, kernel, patches, settings, all reiserfsck **
** messages (including version), the reiserfsck logfile, **
** check the syslog
Re: Testimonials page
Could you close this thread already??? Get back on topic??? Like arguing how files as directories breaks a program written in 1879 by H G Wells, and that it's too political to fix the line of code (which, incidently, says 'Hello World') and we just _can't_ (and I can't stress it enough) merge ReiserFS because this is a _crucial_ application used to measure the tensile strength of Peni (and yes, roaming in groups they're Meece). Oh, if you're 15 years or younger, don't read the last sentence. LiFers. P.S. Seeing as I'm only halfway through reading reiser4 plugins I may be a little out of date. But I'm telling you, it aint broke, and I can't see any use for being in date, so I'm not going to update, and no I WILL NOT MERGE! Anyway, there is no use for being up to date so what's the point? I mean I can't see any use, so obviously it is completely and utterly useless from all points of view. P.P.S Sarcasm is just one more free service I offer. P.P.P.S Bitching is the other. P.P.P.P.S Incidently, if you feed the 'Hello World' program human blood, it unlocks an artificial intelligence that takes over the world through computers. - Original Message - From: Hans Reiser [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: reiserfs-list@namesys.com Sent: Tuesday, July 19, 2005 8:16 PM Subject: Re: Testimonials page Kris Van Bruwaene wrote: There actually is an International Standard on this (ISO-31-0), have a look at: http://www.answers.com/topic/iso-31 which states: * Numbers consisting of long sequences of digits can be made more readable by separating them into groups, preferably groups of three, separated by a small space. ISO 31-0 specifies that such groups of digits should never be separated by a comma or point, as these are reserved for use as the decimal sign. * ISO 31-0 specifies that the decimal sign is the comma on the baseline, but recognizes that in English documents a dot on the line is also commonly used. The french have long controlled the ISO standards process. In this case, it is probably a good standard though. Spaces work for my mind
Fastest way to find / -mtime +7.....
I've got a lot of small maildir files stored on a reiser-fs partition. Currently we expire out the old stuff using find /mail -mtime +7 -type f -print0 | xargs -0 rm -rf this is pretty slow on reiser, at least compared with ext2/3, and I understand that it may be because the find command returns the names in a non-optimal order (ie readdir order?). Is there something we can do to speed it up? Any suggestions? Thanks- Ed
Re: Fastest way to find / -mtime +7.....
On Tue, Jul 19, 2005 at 12:48:53PM -0600, Jonathan Briggs wrote: this is pretty slow on reiser, at least compared with ext2/3, and I understand that it may be because the find command returns the names in a non-optimal order (ie readdir order?). I think Reiser3 is slow more because with mtime, find has to stat each file. The two issues are related. Readdir will return the filenames in hash order. Find will then go and stat each file, still in hash order. Problem is, the inodes are not sorted in directory hash order on the disk. They tend to be in approximate creation order. So, the disk access pattern is nearly random access, meaning every stat is likely to touch a new block and readahead is completely useless. I once wrote a new hash for reiserfs3 specifically for maildir. This hash caused files to be order in approximate creating order, matching the inode order much closer. You will find both the patch and some benchmark results if you search the archive (messageid [EMAIL PROTECTED]), but speeded up my testcase by a factor of 6. (My testcase read all the data too though. I don't think I ever tested just find . -ls) In reiserfs3 the usefullness of the hash is limited as hashes are per filesystem settings. (So it is only useful if you have a dedicated maildir filesystem). I've lost track of reiserfs4 features - maybe you can select hashes per directory now? Or maybe the whole thing is made obsolete by putting the inodes with the directoryentries? -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter
Re: Fastest way to find / -mtime +7.....
On Tue, 2005-07-19 at 22:09 +0200, Ragnar Kjørstad wrote: On Tue, Jul 19, 2005 at 12:48:53PM -0600, Jonathan Briggs wrote: this is pretty slow on reiser, at least compared with ext2/3, and I understand that it may be because the find command returns the names in a non-optimal order (ie readdir order?). I think Reiser3 is slow more because with mtime, find has to stat each file. The two issues are related. Readdir will return the filenames in hash order. Find will then go and stat each file, still in hash order. Problem is, the inodes are not sorted in directory hash order on the disk. They tend to be in approximate creation order. So, the disk access pattern is nearly random access, meaning every stat is likely to touch a new block and readahead is completely useless. [snip] How about some kind of stat-data readahead logic? If the first two or three directory entries are stat'd, queue up the rest (or next hundred/thousand) of them. If the disk queue is given the whole pile of stat requests at once instead of one at a time, it should be able to sort them into a reasonable order. This might even be a VFS thing to do instead of per-FS. -- Jonathan Briggs [EMAIL PROTECTED] eSoft, Inc. signature.asc Description: This is a digitally signed message part
Top software brands and independece you can trust.
Any software backups for lowest pricest. http://yxqjo.ovsl95ohly6vlp6.retypekmdbh.com Everybody loves to see justice done on somebody else. What happens when the future has come and gone?
