Re: Testimonials page
LiFe wrote: Could you close this thread already??? Ok, I concede to the force of your argument.. ;-) Hans
Re: Fastest way to find / -mtime +7.....
Jonathan Briggs wrote on Tue, 19 Jul 2005 16:00:23 -0600: On Tue, 2005-07-19 at 22:09 +0200, Ragnar Kjørstad wrote: 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. I noticed the same limitation for reading large numbers of attributes in BeOS (like icons for all the files in a directory or in the result set from a query). My idea is to expand ReadDir to return more than just the file names in the directory/query. You would specify which metadata you wanted (mtime, filename, attribute name, etc) and then SuperReadDir would traverse the directory/query and pack all the requested data items into one memory buffer for the calling program to use. Thus avoiding the overhead of multiple kernel calls for each individual file. Suddenly displaying a file browser window with a directory with thousands of files is many times faster! But for full functionality this needs a global metadata naming and typing system, so you can find out what data types are available, and how to process them. It would describe mtime as being a 4 byte integer time, SMALL_ICON as being a bitmap, FILE_NAME as being a variable length string and so on. This can be related to the file type system (like the nice one Apple now has in OS X Tiger), so that file types and metadata types can be described by a common API. Unfortunately BeOS has them as separate systems (a list of four character codes for the metadata types, MIME strings for the files). Then there's the issue of cross platform type sharing, an enum with different values here and there for the metadata type codes will make it hard to share data discs, so something more sophisticated is needed... - Alex
reiser4progs do not handle the reiser4 format changes
Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Thanks, Lena
Re: Fastest way to find / -mtime +7.....
On Jul 19, 2005 16:00 -0600, Jonathan Briggs wrote: 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. This is something I would be very interested in. Having a pipeline of stats generated when an app does readdir + in-order stat would help reduce latency a great deal for network filesystems. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. pgprQT5yfDILL.pgp Description: PGP signature
Re: reiser4progs do not handle the reiser4 format changes
E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool?
Re: Fastest way to find / -mtime +7.....
On Wed, Jul 20, 2005 at 12:26:44PM -0400, Andreas Dilger wrote: On Jul 19, 2005 16:00 -0600, Jonathan Briggs wrote: 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. This is something I would be very interested in. Having a pipeline of stats generated when an app does readdir + in-order stat would help reduce latency a great deal for network filesystems. What about just adding an asyncron stat to aio ? -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter
resize.reiser4
Where can I find 'resize.reiser4'? It is not in 'reiser4progs-1.0.4.tar.gz', there are only it's man page there. In Google, all I could find is the man page. -- Lucas Clemente Vella [EMAIL PROTECTED]
Re: Installing Fedora Core with root on Reiserfs
Russell Coker wrote: 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. Sorry for the confusion. My phrase reiserfs.ko located on reiserfs sounds bad, and I should clarify that the reiserfs.ko is contained in the initrd with other binaries/scripts, and this initrd looks fine from the standpoint of kernel/reiserfs, but not from the standpoint of grub/reiserfs-emulation. The logs obtained from serial console don't include anything about loading initrd, and there is the following detail: a dump created by debugreiserfs -d shows that the initrd (i_size: 1128235) is represented by an indirect item (276 4K-blocks), while grub found that this is not sector-aligned: debugreiserfs: -- | 0|54 17448 0x1 IND (1), len 1104, location 2992 entry count 0, fsck need 0, format new| 276 pointers [ 1347049(276)] ^^^ grub: -- grub blocklist /boot/initrd-2.6.11-1.1286_FC4smp.img (hd0,4)10776392[10-512],10776393+15,10776408[0-10],10776408[10-512],10776409+15,... ...,10778584[10-512],10778585+11 (the actual dump is large, so I have cut the middle) This blocklist doesn't contain last zeroed sectors 10778596-10778599 occupied by the initrd, but I am not sure if it is essential. The mysterious offset 10 looks more suspiciously. I'll look at grub internals which are responsible for accessing reiserfs.. Thanks to everyone, Edward.
Re: Installing Fedora Core with root on Reiserfs
On Thursday 21 July 2005 10:04, Edward Shishkin [EMAIL PROTECTED] wrote: My phrase reiserfs.ko located on reiserfs sounds bad, and I should clarify that the reiserfs.ko is contained in the initrd with other binaries/scripts, and this initrd looks fine from the standpoint of kernel/reiserfs, but not from the standpoint of grub/reiserfs-emulation. The logs obtained from serial console don't include anything about loading initrd, and there is the following detail: a dump created by debugreiserfs -d shows that the initrd (i_size: 1128235) is represented by an indirect item (276 4K-blocks), while grub found that this is not sector-aligned: Might this be related to the size of the ReiserFS file system? I tested installs with the default partitioning (100M /boot) which worked OK. When you had the problem were you using a larger ReiserFS file system? -- 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: reiser4progs do not handle the reiser4 format changes
David Masover wrote: E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. Good, so I don't have to reformat _immediately_... But, why isn't it for 2.6.12 yet? We're already on at least 2.6.12.2, last I checked... The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Will there be a conversion tool? No. Reiser4progs just will support a set of new plugins which have been added to the kernel. In particular, mkfs.reiser4 should allow user to specify the plugins like other existing ones. This will be a way to create cryptcompress files per superblock. There is another more flexible way (which is compatible with the previous one) to create it per file/directory, but it uses deprecated metas interface.. Note: since cryptcompress plugin is unstable, the new options are supposed to be undocumented. Thanks, Edward.
Re: reiser4progs do not handle the reiser4 format changes
E.Gryaznova wrote: Notification: The reiser4 format was changed in reiser4-for-2.6.11-5.patch and new reiser4 kernel code is able to handle the old format. The reiser4progs-1.0.4 are not able to handle the format changes. The fix for reiser4progs will be ready next week. Thanks, Lena I would like to apologize to the users for this, it should not have been done this way.
