There is basically no preference, general the faster the drive is and less seek time is better rule applies as always. On the other hand almost every hard drive manufacturer has a widely known broken series of hard drives.
These are known to fail very often , to the point that you probably don't want to use them even if you already paid for them. Also other Deskstar drives are seem to be a not very good choice. These drives are also known to be very sensitive to temperature conditions and are known to fail on overheating. There is class action lawsuit against IBM on that drives series.
Use the most recent version of RedHat gcc 2. The choice of an unstable unreleased version of gcc 2. There are two gcc: 2. Read the Linux kernel instructions about what compiler to use. The solution to code not working on broken compilers is the one RedHat has taken - fix the compiler. They fixed the compiler and thereby allowed the correctly compiled ReiserFS to work. The main thing to remember is that fsyncs introduce a bunch of disk writes, and force the FS to wait on the buffers.
The key to keeping performance up is to make it easy for the FS to do as much as possible before the fsync call. So, if your application modifies 3 files, and you want to make sure all 3 changes are safely on disk:.
It is also faster to write over existing bytes in the file than it is to append new bytes onto the end of a file. When you overwrite existing bytes in the file, you don't have to commit new metadata to disk on fsync , the FS can just write the data blocks. This is fewer seeks. The more you write to a single file before calling fsync , the faster overall things will run.
You have to understand that even using fsync after every write makes no guarantees. If the system crashes during either the write or fsync operation your data may be lost or corrupted. Suppose the fsync does complete, does your application keep its data in multiple files?
If that is the case and you need to write to multiple files as part of a transaction, you have even greater problems. The only safe and easy way for you to implement some kind of transaction with the traditional file system guarantees is to use rename :. One can implement something like a phase-tree at user-level and use rename to atomically switch root of the tree.
This overcomes the "everything-in-one-file" limitation but has the added complexity of requiring crash-recovery. Stop your development for now and wait until Reiser4 filesystem will be released, that has transaction API exported to the userspace. That transaction API would solve all of your problems. Traditional file systems typically have poor performance when there are many files in a single directory, but not ReiserFS.
These other file systems perform poorly because they use a linear search algorithm to find and replace entries in a directory. This means that the file system must scan, on average, half the blocks of a directory for every access. Typically, applications are required to work around this problem by manually structuring a tree of directories, allowing each individual directory to remain limited in size.
For example, see how the Squid web proxy stores a large collection of files. ReiserFS does not have this problem because it uses an internal tree to store all directories and file metadata.
Directory operations remain effecient even for very large directories, so you can write your application free from this performance concern. However, there are several issues that complicate this matter: namely locking and locality. The Linux VFS currently imposes locking restrictions that serialize many operations on directories, so if concurrent processes or threads will access the collection of files then you may be better off using multiple directories.
Reiser4 will improve upon this restriction, although it is still under development. ReiserFS attempts to store all of the files in a directory, along with the directory itself, in nearby locations on disk. An application may exploit this spatial locality if it can predict which files will be accessed with temporal locality. You may be better of using multiple directories to store your files if you can predict that many files within a directory will be accessed at the same time.
To summarize, ReiserFS supports efficient access to large directories and most traditional file systems do not. However, locking and locality issues may guide your decision to use manually structured directory trees instead, at least until ReiserFS exports control over packing locality to users, and improves its locking. Jump to: navigation , search. Categories : ReiserFS Reiser4.
Views Page Discussion View source History. Contents 1 What are the specs for ReiserFS: maximum number of files, of files a directory can have, of sub-dirs in a dir, of links to a file, maximum file size, maximum filesystem size, etc.? Mounting takes several minutes. Once mounted, an ls 1 in the mounted directory hangs. Once the RAID is sync'ed, things appear to work pretty well. How that can be fixed? Any caveats? Does it mean there is no risk of data loss?
I'm not compiling with a buggy compiler. What is happening? How can this be stable? This effectively prevents the disk from spinning down, i. APM modes to take over, even when I'm not writing anything.
How to fix it? This option is required when the journal is already on a separate device from the main data device although it can be avoided with --no-journal-available. If you don't specify journal device by this option, reiserfstune suppose that journal is on main device.
This might happen if a disk goes bad and you remove it and run fsck. If you don't specify this, reiserfstune supposes that journal device remains the same. When journal is to be on a separate device - its size defaults to number of blocks that device has. When journal is to be on the same device as the filesytem - its size defaults to amount of blocks allocated for journal by mkreiserfs when it created the filesystem. Minimum is for both cases. Default is 0. Has no effect when journal is to be on the same device as the filesystem.
Most users have no need to use this feature. It can be used when you want the journals from multiple filesystems to reside on the same device, and you don't want to or cannot partition that device. The default, and max possible, value is blocks. It should be less than half the size of the journal. If specifed incorrectly, it will be adjusted.
The list is added to the fs list of bad blocks. If you put , files in one directory, we think its fine; many other file systems try to tell you that you are wrong to want to do it. ReiserFS is more space efficient. If you write byte files, we pack many of them into one block.
Other file systems put each of them into their own block. We don't have fixed space allocation for inodes. Ok, it's time to fess up. The interesting stuff is still in the future.
0コメント