Re: kmail corrupts emails [solved]
Derek Broughton wrote: > Randy Kramer wrote: > > >>On Tuesday 27 September 2005 09:27 am, Derek Broughton wrote: >> >>>Why do you think Maildir would perform worse for folders with thousands >>>of >>>emails? Everything I've read suggests it will perform better - and more >>>reliably. >> >>First a quick (but dumb, I should look it up) question. Does Linux do the >>thing that Dos/Windows does (used to do?) of each file requiring a minimum >>space (one cluster?), or does it vary by filesystem? > > > It varies decidedly between the different filesystems. I think the restriction that you're more likely to run into is the number of inodes available (which are predetermined when you setup an ext2/3 filesystem). However, ReiserFS is *much* more efficient when you have thousands of files in one directory, because it uses a hashing algorithm to determine where the required file is (or starts) in the filesystem. This is something I know about (hashing) based on my experience with Pick database systems, which also use hashing and are incredibly fast at keyed record retrieval (as well as entire file/table traversal). I've used ReiserFS in the past mainly for it's journalling capability, which at the time was more complete than ext3's (this was on a RH6.2 system with the 2.4.x series kernels). As my customers at the time were very likely to simply switch the system off (for any reason, including not knowing how a particular application works that they'd wandered into), this feature saw a lot of (successful) use! [snip] -- PeteJ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kmail corrupts emails [solved]
Randy Kramer wrote: > On Tuesday 27 September 2005 01:44 pm, Pete Jewell wrote: > >>However, ReiserFS is *much* more efficient when you have thousands of >>files in one directory, because it uses a hashing algorithm to determine >>where the required file is (or starts) in the filesystem. This is >>something I know about (hashing) based on my experience with Pick >>database systems, which also use hashing and are incredibly fast at >>keyed record retrieval (as well as entire file/table traversal). >> > > > Thanks to Derek, Hendrik, and Pete for the replies! > > Is there a chance that the hash for a ReiserFS can become corrupted like the > index for a mbox file can be? Or maybe I should ask it differently, because > presumably something can happen to make it corrupted--does Reisers have some > better error detection / correction / recovery for the hash than is typical > of an index for an mbox file? > > (Maybe I need to go read up on Reiser, and join a Reiser list. ;-) The beauty of a hash that is used to locate a file, or record, is that it is based on the key, or filename in the case of ReiserFS (actually, not having looked at the internals of ReiserFS I'm assuming it's the filename - it could conceivably be anything that stored against the inode). The important thing is that we have something that we can use within a mathematical expression to determine where on the filesystem the beginning of the file can be found. In Pick the filesystem (and memory) is organised into frames. The location of a piece of data within that space can be determined mathematically, at least to a pointer that shows where the data starts. The frames are usually quite small so that there's no performance hit in loading it into memory and scanning it for the exact location within it (helped with the use of delimiters between tables, records, fields, and even fields within fields). The version of Pick I use at work (D3) uses 4K frames, but they've ranged from 512 bytes upwards in various implementations over the years. As such, finding the file is not as susceptible to corruption (unless the inode gets trashed, same risk there), as there is no index. Time to retrieval is drastically reduced as there's no index to follow, just some integer math. However the files themselves wouldn't inherently be less susceptible to corruption - but that's where a (full) journal can help out. HTH -- PeteJ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kmail corrupts emails [solved]
Derek Broughton wrote: > Pete Jewell wrote: > > >>However, ReiserFS is *much* more efficient when you have thousands of >>files in one directory, because it uses a hashing algorithm to determine >>where the required file is (or starts) in the filesystem. This is >>something I know about (hashing) based on my experience with Pick >>database systems, which also use hashing and are incredibly fast at >>keyed record retrieval (as well as entire file/table traversal). > > > There's a blast from the past. I did too much work with Pick databases... I > managed not to learn anything more about hashing, too. There's no such thing as /too much work with Pick databases/ ;-) Actually, the company I work for are just about to start a pilot of a system that will replace the D3 one I maintain. If all goes well it'll get turned off in a couple of years. To be honest I'm looking forward to cross-training onto the new system - Pick permanent jobs are becoming harder and harder to come by (not to mention having to travel - I do a 150 mile round trip each day to get to work and back). Contract work is a little easier to find (lots of tending existing systems, while they're being replaced!). That being said I still really enjoy working in Pick - you can go from the client's initial idea to something tangible so quickly, they think that you're some sort of genius (considering how long it takes their requests to get actioned on the SQL backed systems!) :-) -- PeteJ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE 3.4.2 backport now?
Klaus Becker wrote: > Le Jeudi 29 Septembre 2005 22:49, Mikhail Ramendik a écrit : > >>Klaus Becker wrote: >> http://mirror.debianforum.de/kde-3.4.2/ >>> >>>I tried it and I got: >> >>This is the output of what? >> >> >>>grave bugs of kdm (4:3.4.1-1 -> 4:3.4.2-2) >>> #324018 - kdm does not have the binary in the package anymore >>> #327273 - kdm does not start xorg server > > > this is the issue of "apt-get upgrade" with the above sources. So I did not > continue. Hang on, doesn't the after the version numbers mean that these particular bugs have been fixed/closed? -- PeteJ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
