Re: [reiserfs-list] 2.4.6 is out .. reiserfs patch needed ?
Eric Whiting wrote: This generation number thing confuses/kills a single solaris 2.8 NFS client for something as simple as doing a ./configure of bonnie++ on a linux NFSV2 server. Neil Brown observed the same problem on a Solaris 2.6 client. I can't ./configure bonnie++ no matter what I try without this generation number patch. It doesn't seem to be optional for me. Yet it is true that only certain actions trigger the bug -- but ./configure is a common activity in my world. Smells like a bug somewhere. Lack of inode generation numbers should not cause this if there is only a single client and no other concurrent access to the filesystem after this single client have booted. My guess is a NFS client cache management bug, hidden by having support for inode generation numbers on the server. But still, inode generation number are more or less required for guaranteed proper NFS operation. -- Henrik Nordstrom
[reiserfs-list] reiserfs-raw
ReiserFS developers: What is the status of the reiserfs-raw branch? Is it still being maintained, or has it been completely postponed awaiting finding space/resources/time for a more generic filesystem interface mechanism for such applications? The last known release of reiserfs-raw is 2.4.0-test10-reiserfs-raw, but this patch contains many things not actually part of the reiserfs-raw changes (i.e. the whole of reiserfs, AIO, hotswap capabilities, and from what it seems a bunch of more or less unrelated patches), with no references to which versions these are based on, making it increasingly hard to maintain such a kernel. It would be a shame to let all this work go down the drain I think. -- Henrik Nordstrom Squid Developer
Re: [reiserfs-list] reiserfs-raw
Nikita Danilov wrote: The last known release of reiserfs-raw is 2.4.0-test10-reiserfs-raw, but this patch contains many things not actually part of the reiserfs-raw changes (i.e. the whole of reiserfs, AIO, hotswap capabilities, and from what it seems a bunch of more or less unrelated patches), with no references to which versions these are based on, making it increasingly There were so much hurry before cache-off... True. It was a bit rushed then, but it did manage to successully complete a cache backeoff... -- Henrik Nordstrom Squid developer
Re: [reiserfs-list] File corruption in journal replay
Jonathan Hseu wrote: I run kernel 2.4.5, SMP + reiserfs, and I was copying a file, when I crashed and rebooted. After reboot, I compared the file that was copying, and found that they differed. What should happen is that the two files should be equivalent up until the position of the end of the file that it was copying to. Not neccesarily. Reiserfs only guarantees that directory and filesystem structures will be intact, not that data currently being written is. In fact, if you extend a file and then crash before writes to the extended area have hit the disk then file may contain just about anything. In case of tails you may even loose some of the information that was on disk previously. It can be argued if this is good or bad, but it is how it currently works, and can be seen in any filesystem only doing metadata journaling or no journaling at all (i.e. the precisely the same will happen in ext2) Only major issue I see is a small security leak as such crashed files may contain random information from other deleted/rearranged files. The data integrity issues in event of crash is what we have fsync() and friends for. -- Henrik Nordstrom
Re: [reiserfs-list] ReiserFS 3.5.32 stability ?
Vladimir V. Saveliev wrote:
It is doable, but afaics now it looks almost useless as far as st_nlink is 16 bit
even in stat64.
glibc uses int for link count (all modes).
typedef __u_int __nlink_t; /* Type of file link counts. */
kernel stat uses short
struct stat {
[...]
unsigned short st_nlink;
kernel stat64 also uses int
struct stat64 {
[...]
unsigned intst_nlink;
and in case of stat, link counts above a couple of hundreds is rarely
important, so for most practical uses returning 65535 for counts above
65535 is perfectly fine.
libc also will have to change, and that will probably make problems for existing
programs.
libc is already using int for both stat and stat64.
--
Henrik Nordstrom
