PERFORMANCE OF FILESYSTEMS COMPARED (includes Reiser4 and Ext4).

[Jade]

PERFORMANCE OF FILESYSTEMS COMPARED
(includes Reiser4 and Ext4)

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://linux.50webs.org/resources/fs-benchmarks.htm

RESULT: With compression, REISER4, absolutely SMASHED the other filesystems.

No other filesystem came close (not even remotely close).

Using REISER4 (gzip), rather than EXT2/3/4, saves you a truly amazing 816 - 213 = 603 MB (a 74% saving in disk space), and this, with little, or no, loss of performance when storing 655 MB of raw data. In fact, substantial performance increases were achieved in the bonnie++ benchmarks.

We use the following filesystems:

REISER4 gzip: Reiser4 using transparent gzip compression.
REISER4 lzo: Reiser4 using transparent lzo compression.
REISER4 Standard Reiser4 (with extents)
EXT4 default Standard ext4.
EXT4 extents ext4 with extents.
NTFS3g Szabolcs Szakacsits' NTFS user-space driver.
NTFS NTFS with Windows XP driver.

Disk Usage in megabytes. Time in seconds. SMALLER is better.


.-------------------------------------------------.
|File |Disk |Copy |Copy |Tar |Unzip| Del |
|System |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type | (MB)| (1) | (2) |655MB|655MB| Gig |
.-------------------------------------------------.
|REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 |
|REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 |
|REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 |
|REISER4 | 692 | 148 | 55 | 67 | 25 | 56 |
|NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 |
|NTFS | 779 | 781 | 173 | X | X | X |
|REISER3 | 793 | 184 | 98 | 85 | 63 | 22 |
|XFS | 799 | 220 | 173 | 119 | 90 | 106 |
|JFS | 806 | 228 | 202 | 95 | 97 | 127 |
|EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 |
|EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 |
|EXT3 | 816 | 182 | 74 | 73 | 43 | 51 |
|EXT2 | 816 | 201 | 82 | 73 | 39 | 67 |
|FAT32 | 988 | 253 | 158 | 118 | 81 | 95 |
.-------------------------------------------------.


WHAT THE NUMBERS MEAN:

The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
It comprised 3 different copies of the Linux kernel sources.

Disk Usage: The amount of disk used to store the data.
Copy 655MB (1): Time taken to copy the data over a partition boundary.
Copy 655MB (2): Time taken to copy the data within a partition.
Tar Gzip 655MB: Time taken to Tar and Gzip the data.
Unzip UnTar 655MB: Time taken to UnGzip and UnTar the data.
Del 2.5 Gig: Time taken to Delete everything just written (about 2.5 Gig).

Each test was preformed 5 times and the average value recorded.

To get a feel for the performance increases that can be achieved by using compression, we look at the total time (in seconds) to run the test:

bonnie++ -n128:128k:0 (bonnie++ is Version 1.93c)


.-------------------.
| FILESYSTEM | TIME |
.-------------------.
|REISER4 lzo | 1938|
|REISER4 gzip| 2295|
|REISER4 | 3462|
|EXT4 | 4408|
|EXT2 | 4092|
|JFS | 4225|
|EXT3 | 4421|
|XFS | 4625|
|REISER3 | 6178|
|FAT32 | 12342|
|NTFS-3g |>10414|
.-------------------.


The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen in the first test above where compression often does not speed things up. However, more importantly, it does not slow things down much, either.

http://linuxhelp.150m.com/resources/fs-benchmarks.htm
http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

[mlau]

Very nice summary, thank you.

RESULT: With compression, REISER4, absolutely SMASHED the other filesystems.

I've been using Reiser4 since it first hit -mm series. While it really IS
very fast (no FS untars a kernel tarball faster), it has two major flaws:
1. it maintains too large in-memory caches. When it decides to write its
huge caches back to disk, my system gets unresponsive for ~5secs (even
mouse cursor freezes sometimes).
EDIT: this is also a problem with sudden power loss. I lost *LOTS* of files
on reiser4 partitions this way.

2. it does not reserve a tiny amount of diskspace for "emergency" use when
the disk gets full. This is especially annoying if you use it as rootfs:
disk gets full and you can't launch any apps (not even rm!, heck I can't
even shut the machine down properly).

[Jade]

this is also a problem with sudden power loss. I lost *LOTS* of files on reiser4 partitions this way.
I can't say the same. Apart from Morton's sabotaged Reiser4, I have never lost a file.

[mlau]

Apart from Morton's sabotaged Reiser4,

care to expand on that statement?

I ditched Reiser4 for XFS because I'm using latest -git sources nowadays; hunting down patches to get R4 working on those sources got annoying...

[Jade]

care to expand on that statement
See the comment by edged: @

http://www.phoronix.com/forums/showthread.php?t=7544&page=5

and the article: "The Linux Kernel Saboteurs." @

http://linuxhelp.150m.com/jews/saboteurs.htm

[ddoan]

Come on, why do you always have to link to this damn nazi website? A website where things like "Jews are evil people" are stated. This is all so ridiculous

[yoshi314]

yeah, no wonder my spam detector feels trigger-happy.

i still prefer reliability to performance. i've had a big data corruption with reiser4 done in quite a trivial way, and i don't feeling like trying again for now.

fortunately it was non-critical data, but still the bad impression remains.

[butdie]

Very nice summary, thank you.



I've been using Reiser4 since it first hit -mm series. While it really IS
very fast (no FS untars a kernel tarball faster), it has two major flaws:
1. it maintains too large in-memory caches. When it decides to write its
huge caches back to disk, my system gets unresponsive for ~5secs (even
mouse cursor freezes sometimes).
EDIT: this is also a problem with sudden power loss. I lost *LOTS* of files
on reiser4 partitions this way.

2. it does not reserve a tiny amount of diskspace for "emergency" use when
the disk gets full. This is especially annoying if you use it as rootfs:
disk gets full and you can't launch any apps (not even rm!, heck I can't
even shut the machine down properly).

the first problem is a really trouble for me. it freezes from time to time not only for 5 seconds, but 5+ mins, or even 30 mins! the cursor still moves, but firefox would freeze. as far as I'm aware of, there's no fix yet. user may specify smaller cache, but it doesn't really improve the freezes, just slows the fs down

[Pseus]

the first problem is a really trouble for me. it freezes from time to time not only for 5 seconds, but 5+ mins, or even 30 mins! the cursor still moves, but firefox would freeze. as far as I'm aware of, there's no fix yet. user may specify smaller cache, but it doesn't really improve the freezes, just slows the fs down

It may be wise to report this to the ReiserFS development mailing list.

In any case, the benchmarks posted by the OP are somewhat old. A new set of benchmarks is needed. Unfortunately, development has been slow and I don't see reiser4 making big progress as long as there are only a couple of devs that can work on it part-time.

[BlueKoala]

Come on, why do you always have to link to this damn nazi website? A website where things like "Jews are evil people" are stated. This is all so ridiculous

lol
Some opinions are extreme and maybe hateful, although the point of view is definitely interesting (The sabotage part). In case it really is a big conspiracy, it would then be more obvious who the culprit would be when Namesys gets bought out by it once the value of the company hits rock bottom.

I'd be interested to have reiser4 in my kernel to test it with unimportant data on a seperate drive. I could live with HDD performance going through the roof, even if it doesn't conform with kernel development standards.

[deanjo]

Come on, why do you always have to link to this damn nazi website? A website where things like "Jews are evil people" are stated. This is all so ridiculous


Agreed, personally I'm surprised Michael even allows such subliminal practices that Jade uses to even be allowed on the forums. Jade could just as easily use pastebin.

[Jade]

the first problem (with Reiser4) is a really trouble for me. it freezes from time to time not only for 5 seconds, but 5+ mins, or even 30 mins! the cursor still moves, but firefox would freeze.
Never happened. Not even once.

i still prefer reliability to performance. i've had a big data corruption with reiser4 done in quite a trivial way, and i don't feeling like trying again for now.
You were using one of the sabotaged versions of Reiser4.

Go to the article: "The Linux Kernel Saboteurs." @

http://linuxhelp.150m.com/jews/saboteurs.htm and read about it.

Come on, why do you always have to link to this damn nazi website? A website where things like "Jews are evil people" are stated. This is all so ridiculous
Does it say that?

[joshuapurcell]

Everyone, please pay close attention to the link Jade has posted... actually, no need to pay too close attention. Just read the link, and notice that he the section of his website he just linked to is the jews section, with the page itself entitled saboteurs.

Please kick this bastard off this forum. He has no place posting anything here any longer.

[Jade]

2. it does not reserve a tiny amount of diskspace for "emergency" use when
the disk gets full. This is especially annoying if you use it as rootfs:
disk gets full and you can't launch any apps (not even rm!, heck I can't
even shut the machine down properly).
I don't actually think that is true.

But even IF it is. A simple little bit of recoding would fix the situation.

[LavosPhoenix]

Everyone, please pay close attention to the link Jade has posted... actually, no need to pay too close attention. Just read the link, and notice that he the section of his website he just linked to is the jews section, with the page itself entitled saboteurs.

Please kick this bastard off this forum. He has no place posting anything here any longer.

Why? Are Jews some sort of magical group of people that can't be evil or saboteurs? Just because they are supposedly protected by a mythological being (WHICH MAN CREATED), doesn't make them automagically non-evil forever under any circumstances.

Look at the evidence, some people have obviously sabotaged Reiser4. I don't know if those follow Judaism, but if they do, that would probably classify them as a Jew, and thus the OP's assumptions would be CORRECT.

If you are going to claim sort sort of anti-semitic oppression because of this, then I'm going to claim opression from ATI for not providing drivers that WORK AS WELL AS THEY DO ON WINDOWS. And under the same ridiculous argument used for religious oppression, If you disagree with me, oh shit, "HALP, I'M BEING OPRESSED! I NEED THOSE LANDS SOME IMAGINARY FRIEND GAVE TO US THOUSANDS OF YEARS AGO!" See how ridiculous that is? Exactly. So present evidence that what the OP said was untrue, if in fact it is.

[StringCheesian]

I think the most reasonable assumption, until proven otherwise, is that Judaism and other religions have absolutely nothing to do with Hans Reiser or his filesystem.

Instead, I propose that Reiser and his filesystem have been the victim of a conspiracy among tall people, basketball players especially.

Sure, you might say I sound like a crazy conspiracy theorist, but consider: Are Tall People some sort of magical group of people that can't be evil or saboteurs?

Look at the evidence, some people have obviously sabotaged Reiser4. I don't know if those are tall, but if they are, that would probably classify them as Tall People, and thus the my assumptions would be CORRECT.

You can't rule out Tall People - they remain a possible explanation as well.

[givemesugarr]

See the comment by edged: @

http://www.phoronix.com/forums/showthread.php?t=7544&page=5

and the article: "The Linux Kernel Saboteurs." @

http://linuxhelp.150m.com/jews/saboteurs.htm

where are the test_and_set_bit () and inc_zone_page_state() functions definitions?!
it's not possible to know if the new patch works in the same way as it was supposed to work or if in the new way it works better than before.

[givemesugarr]

Never happened. Not even once.


You were using one of the sabotaged versions of Reiser4.

Go to the article: "The Linux Kernel Saboteurs." @

http://linuxhelp.150m.com/jews/saboteurs.htm and read about it.


Does it say that?

well, in reality there is a mass world conspiracy to kill reiser and his overwhelming filesystem. and it is lead by andrew morton and linus torvalds.

f****, try to get to reality and drop this bullsh**. it's simple to say the same thing with only one article that says this and that doesn't even reports all the original stuff. that has been changed and the new one, which would also describe what the 2 codes would do and explain the differences between them. in this way real devs could understand if the writer of this article is a real dev and understands what he says and not only a spammer of idiocy....

well, as for reiser, if really it would really have been sabotated by morton, it would be nice to know why he still tries his best to have it included into mainstream kernel. it's really a mystery to me. after the first drop by linus he would have really dropped it, since it was already sabotated, instead of losing his time on it. or maybe he is an immortal vampire that has a lot of time to spend on useless stuff.

[metala]

Do you know that the developer of ReiserFS (aka Reiser3), Hans Reiser is accused for murdering his wife?

[givemesugarr]

Do you know that the developer of ReiserFS (aka Reiser3), Hans Reiser is accused for murdering his wife?

what does this has to do with andrew morton to sabotage the reiser4 fs?! as far as i know andrew is one the people who mostly pushes for reiser4 to being included into the official kernel. if really there was a conspiracy with him involved what reason would he have to continue on this line?!

[metala]

Do you know that the developer of ReiserFS (aka Reiser3), Hans Reiser is accused for murdering his wife?what does this has to do with andrew morton to sabotage the reiser4 fs?! as far as i know andrew is one the people who mostly pushes for reiser4 to being included into the official kernel. if really there was a conspiracy with him involved what reason would he have to continue on this line?!

;)
You didn't understand me ... I thought it will be so.
It was a joke.. lol .. sorry for that, I have an excuse - I was on caffeine.

On the topic: very impressive results.. I still don't know why it's not implemented in kernel mainstream...

[Historian]

Why are comments to

The HANS REISER Murder Trial. Timeline and Analysis

http://phoronix.com/forums/showthread.php?t=7544

thread censored?

Is this usual?

[Michael]

Why are comments to

The HANS REISER Murder Trial. Timeline and Analysis

http://phoronix.com/forums/showthread.php?t=7544

thread censored?

Because you're just trying to spew bullshit that doesn't belong in a technology forum.

[givemesugarr]

;)
You didn't understand me ... I thought it will be so.
It was a joke.. lol .. sorry for that, I have an excuse - I was on caffeine.

On the topic: very impressive results.. I still don't know why it's not implemented in kernel mainstream...

i think that the problem lies in the filesystem corruption. for what i've read on the argument, the standards imposed by linus for the filesystems to be included into the kernel are still not matched by reiser4. andrew morton doesn't think like that and it seems that he is pushing towards its introduction into the main branch, even if with experimental as a feature.

what still leaves me a little puzzled is that ext4 is not so much more stable than reiser4 but it has gotten into the main branch. this only means that the file corruption issue of reiser4 is really bad when compared to the one of ext4.

[rbmorse]

Because you're just trying to spew bullshit that doesn't belong in a technology forum.

That's a real good reason. Michael, please continue to enforce that policy with rigor and enthusiasm.

[Jade]

The Linux Kernel SABOTEURS @ http://www.phoronix.com/forums/showthread.php?t=9509

The Linux Kernel Saboteurs.

From http://linuxhelp.150m.com/
and http://linux.50webs.org

Although the Linux kernel saboteurs (a number of so called Linux kernel "developers") have sabotaged many areas of Linux, I will concentrate on their efforts in sabotaging Reiser4.

As some will have noticed, Reiser4 no longer works as it used to. The recent patches of Andrew Morton, and Riffard Laurent, cause corruption problems (when they work at all). Morton's patches, also reduced Reiser4's functionality, removing, for example, the cryptocompress plugin. Riffard's patches include the cryptocompress plugin, which seems to work, but the patch causes corruption for plain Reiser4.

You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.

The parts of Reiser4 they have not touched, still work, but where they have coded, Reiser4 no longer works.

The fact that Reiser4 worked well, before Hans Reiser's arrest and imprisonment (on what appears to be trumped-up charges) and now doesn't, means that it should be easy to spot the sabotage.

After digging around in the source code, the evidence of deliberate sabotage is very clear.

I present some of the evidence (found by comparing Riffard's patch with older Namesys patches) below.

Update: Namesys has released 2.6.20 and 2.6.21 kernel patches. This has enabled one to completely isolate the differences between Namesys' 2.6.20 patch and Riffard's. The diff file is very small and can be found here (../installs/diff-namesys-riffard-2.6.20.txt). The early sabotage is concentrated in this small file.

One act of sabotage, is found in reiser4/page_cache.c:

int reiser4_page_io(struct page *page, jnode *node, int rw, gfp_t gfp)
{
struct bio *bio;
int result;

assert("nikita-2094", page != NULL);
assert("nikita-2226", PageLocked(page));
assert("nikita-2634", node != NULL);
assert("nikita-2893", rw == READ || rw == WRITE);

if (rw) {
if (unlikely(page->mapping->host->i_sb->s_flags & MS_RDONLY)) {
unlock_page(page);
return 0;
}
}

bio = page_bio(page, node, rw, gfp);
if (!IS_ERR(bio)) {
if (rw == WRITE) {
SetPageWriteback(page);
Changed to set_page_writeback(page);
unlock_page(page);
}
reiser4_submit_bio(rw, bio);
result = 0;
} else {
unlock_page(page);
result = PTR_ERR(bio);
}

return result;
}

where SetPageWriteback has been changed to set_page_writeback.

This change is hard to spot with SetPageWriteback and set_page_writeback, being very similar in name. This change is almost guaranteed to cause problems, as set_page_writeback is called without calling end_page_writeback(). According to Documentation/filesystems/Locking, this will leave the page itself marked clean but it will be tagged as dirty in the radix tree. This incoherency can lead to all sorts of hard-to-debug problems in the filesystem like having dirty inodes at umount and losing written data. Just as the saboteurs desire, and what we see happening.

The definition of SetPageWriteback is found in linux-2.6.20/include/linux/page-flags.h,

#define SetPageWriteback(page) \
do { \
if (!test_and_set_bit(PG_writeback, \
&(page)->flags)) \
inc_zone_page_state(page, NR_WRITEBACK); \
} while (0)
as is the definition of set_page_writeback,
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
}

where test_set_page_writeback (from linux-2.6.20/mm/page-writeback.c) is:

int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;

if (mapping) {
unsigned long flags;

write_lock_irqsave(&mapping->tree_lock, flags);
ret = TestSetPageWriteback(page);
if (!ret)
radix_tree_tag_set(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_WRITEBACK);
if (!PageDirty(page))
radix_tree_tag_clear(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_DIRTY);
write_unlock_irqrestore(&mapping->tree_lock, flags);
} else {
ret = TestSetPageWriteback(page);
}
return ret;

}
EXPORT_SYMBOL(test_set_page_writeback);

From the above definitions, it is clear that swapping set_page_writeback for SetPageWriteback was not an accidental mistake (the code is completely different).

The patch, move-page-writeback-acounting-out-of-macros.patch, is Andrew Morton's attempt to completely cover his tracks. He claims it is "inconsistent" and "awkward" to have the three page-writeback accounting macros in include/linux/page-flags.h (together with all the other page macros) and that it would be better somehow, if they were moved to mm/page-writeback.c. However, not a single one of these definitions is actually transfered to mm/page-writeback.c. Two of them have their definition split between the two named files and the third, SetPageWriteback, is "accidentally" lost. It just disappears.

In this way, Andrew Morton completely eliminates all reference to SetPageWriteback in the (2.6.21) mm-kernel.

The patch move-page-writeback-acounting-out-of-macros.patch is presented here:
From: Andrew Morton

page-writeback accounting is presently performed in the page-flags macros.
This is inconsistent and makes it awkward to implement per-backing_dev
under-writeback page accounting.

So move this accounting down to the callsite(s).

Signed-off-by: Andrew Morton
---

include/linux/page-flags.h | 38 +++++++----------------------------
mm/page-writeback.c | 4 +++
2 files changed, 12 insertions(+), 30 deletions(-)

diff -puN include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros include/linux/page-flags.h
--- a/include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros
+++ a/include/linux/page-flags.h
@@ -184,37 +184,15 @@ static inline void SetPageUptodate(struc
#define __SetPagePrivate(page) __set_bit(PG_private, &(page)->flags)
#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)

+/*
+ * Only test-and-set exist for PG_writeback. The unconditional operators are
+ * risky: they bypass page accounting.
+ */
#define PageWriteback(page) test_bit(PG_writeback, &(page)->flags)
-#define SetPageWriteback(page) \
- do { \
- if (!test_and_set_bit(PG_writeback, \
- &(page)->flags)) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestSetPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_set_bit(PG_writeback, \
- &(page)->flags); \
- if (!ret) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
-#define ClearPageWriteback(page) \
- do { \
- if (test_and_clear_bit(PG_writeback, \
- &(page)->flags)) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestClearPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_clear_bit(PG_writeback, \
- &(page)->flags); \
- if (ret) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
+#define TestSetPageWriteback(page) test_and_set_bit(PG_writeback, \
+ &(page)->flags)
+#define TestClearPageWriteback(page) test_and_clear_bit(PG_writeback, \
+ &(page)->flags)

#define PageBuddy(page) test_bit(PG_buddy, &(page)->flags)
#define __SetPageBuddy(page) __set_bit(PG_buddy, &(page)->flags)
diff -puN mm/page-writeback.c~move-page-writeback-acounting-out-of-macros mm/page-writeback.c
--- a/mm/page-writeback.c~move-page-writeback-acounting-out-of-macros
+++ a/mm/page-writeback.c
@@ -987,6 +987,8 @@ int test_clear_page_writeback(struct pag
} else {
ret = TestClearPageWriteback(page);
}
+ if (ret)
+ dec_zone_page_state(page, NR_WRITEBACK);
return ret;
}

@@ -1012,6 +1014,8 @@ int test_set_page_writeback(struct page
} else {
ret = TestSetPageWriteback(page);
}
+ if (!ret)
+ inc_zone_page_state(page, NR_WRITEBACK);
return ret;

}
_

Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:

[givemesugarr]

Morton's patches, also reduced Reiser4's functionality, removing, for example, the cryptocompress plugin. Riffard's patches include the cryptocompress plugin, which seems to work, but the patch causes corruption for plain Reiser4.


did that work?! if it didn't work and it didn't work?! also if the kernel has its own crypto plugin why the hell does a filesystem in the kernel need it?! it will use the kernel api for this.


You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.


hmmm... an example would be better.



The parts of Reiser4 they have not touched, still work, but where they have coded, Reiser4 no longer works.


what are these parts?! what are the parts touched that don't work anymore?!


The fact that Reiser4 worked well, before Hans Reiser's arrest and imprisonment (on what appears to be trumped-up charges) and now doesn't, means that it should be easy to spot the sabotage.


again: where's the proof that it worked fine before?!


After digging around in the source code, the evidence of deliberate sabotage is very clear.

I present some of the evidence (found by comparing Riffard's patch with older Namesys patches) below.

Update: Namesys has released 2.6.20 and 2.6.21 kernel patches. This has enabled one to completely isolate the differences between Namesys' 2.6.20 patch and Riffard's. The diff file is very small and can be found here (../installs/diff-namesys-riffard-2.6.20.txt). The early sabotage is concentrated in this small file.

One act of sabotage, is found in reiser4/page_cache.c:

where SetPageWriteback has been changed to set_page_writeback.

This change is hard to spot with SetPageWriteback and set_page_writeback, being very similar in name. This change is almost guaranteed to cause problems, as set_page_writeback is called without calling end_page_writeback(). According to Documentation/filesystems/Locking, this will leave the page itself marked clean but it will be tagged as dirty in the radix tree. This incoherency can lead to all sorts of hard-to-debug problems in the filesystem like having dirty inodes at umount and losing written data. Just as the saboteurs desire, and what we see happening.

The definition of SetPageWriteback is found in linux-2.6.20/include/linux/page-flags.h,

#define SetPageWriteback(page) \
do { \
if (!test_and_set_bit(PG_writeback, \
&(page)->flags)) \
inc_zone_page_state(page, NR_WRITEBACK); \
} while (0)
as is the definition of set_page_writeback,
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
}

where test_set_page_writeback (from linux-2.6.20/mm/page-writeback.c) is:

int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;

if (mapping) {
unsigned long flags;

write_lock_irqsave(&mapping->tree_lock, flags);
ret = TestSetPageWriteback(page);
if (!ret)
radix_tree_tag_set(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_WRITEBACK);
if (!PageDirty(page))
radix_tree_tag_clear(&mapping->page_tree,
page_index(page),
PAGECACHE_TAG_DIRTY);
write_unlock_irqrestore(&mapping->tree_lock, flags);
} else {
ret = TestSetPageWriteback(page);
}
return ret;

}
EXPORT_SYMBOL(test_set_page_writeback);

From the above definitions, it is clear that swapping set_page_writeback for SetPageWriteback was not an accidental mistake (the code is completely different).

IT'S CLEAR THAT THE CODE IS DIFFERENT, BUT IT'S NOT EVEN 1% CLEAR THAT THE NEW CODE WOULD WORK WORSE. YOU NEED TO EXPLICIT EVERY SINGLE FUNCTION USED IN THIS CODE WITH EVERYTHING THAT IT DOES TO BE ABLE TO SAY THAT THE MODIFIED CODE WORK WORSE. NOW, BEFORE THIS DOCUMENTATION IS SHOWN I'LL CONTINUE TO THINK THAT THE NEW CODE IS BETTER THAT THE OLD ONE.



The patch, move-page-writeback-acounting-out-of-macros.patch, is Andrew Morton's attempt to completely cover his tracks. He claims it is "inconsistent" and "awkward" to have the three page-writeback accounting macros in include/linux/page-flags.h (together with all the other page macros) and that it would be better somehow, if they were moved to mm/page-writeback.c. However, not a single one of these definitions is actually transfered to mm/page-writeback.c. Two of them have their definition split between the two named files and the third, SetPageWriteback, is "accidentally" lost. It just disappears.

HE'S DAMN RIGHT AND USUALLY PROGRAMMERS KNOW THIS TOO.


In this way, Andrew Morton completely eliminates all reference to SetPageWriteback in the (2.6.21) mm-kernel.

The patch move-page-writeback-acounting-out-of-macros.patch is presented here:
From: Andrew Morton

page-writeback accounting is presently performed in the page-flags macros.
This is inconsistent and makes it awkward to implement per-backing_dev
under-writeback page accounting.

So move this accounting down to the callsite(s).

Signed-off-by: Andrew Morton
---

include/linux/page-flags.h | 38 +++++++----------------------------
mm/page-writeback.c | 4 +++
2 files changed, 12 insertions(+), 30 deletions(-)

diff -puN include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros include/linux/page-flags.h
--- a/include/linux/page-flags.h~move-page-writeback-acounting-out-of-macros
+++ a/include/linux/page-flags.h
@@ -184,37 +184,15 @@ static inline void SetPageUptodate(struc
#define __SetPagePrivate(page) __set_bit(PG_private, &(page)->flags)
#define __ClearPagePrivate(page) __clear_bit(PG_private, &(page)->flags)

+/*
+ * Only test-and-set exist for PG_writeback. The unconditional operators are
+ * risky: they bypass page accounting.
+ */
#define PageWriteback(page) test_bit(PG_writeback, &(page)->flags)
-#define SetPageWriteback(page) \
- do { \
- if (!test_and_set_bit(PG_writeback, \
- &(page)->flags)) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestSetPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_set_bit(PG_writeback, \
- &(page)->flags); \
- if (!ret) \
- inc_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
-#define ClearPageWriteback(page) \
- do { \
- if (test_and_clear_bit(PG_writeback, \
- &(page)->flags)) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- } while (0)
-#define TestClearPageWriteback(page) \
- ({ \
- int ret; \
- ret = test_and_clear_bit(PG_writeback, \
- &(page)->flags); \
- if (ret) \
- dec_zone_page_state(page, NR_WRITEBACK); \
- ret; \
- })
+#define TestSetPageWriteback(page) test_and_set_bit(PG_writeback, \
+ &(page)->flags)
+#define TestClearPageWriteback(page) test_and_clear_bit(PG_writeback, \
+ &(page)->flags)

#define PageBuddy(page) test_bit(PG_buddy, &(page)->flags)
#define __SetPageBuddy(page) __set_bit(PG_buddy, &(page)->flags)
diff -puN mm/page-writeback.c~move-page-writeback-acounting-out-of-macros mm/page-writeback.c
--- a/mm/page-writeback.c~move-page-writeback-acounting-out-of-macros
+++ a/mm/page-writeback.c
@@ -987,6 +987,8 @@ int test_clear_page_writeback(struct pag
} else {
ret = TestClearPageWriteback(page);
}
+ if (ret)
+ dec_zone_page_state(page, NR_WRITEBACK);
return ret;
}

@@ -1012,6 +1014,8 @@ int test_set_page_writeback(struct page
} else {
ret = TestSetPageWriteback(page);
}
+ if (!ret)
+ inc_zone_page_state(page, NR_WRITEBACK);
return ret;

}
_

Another, hard to spot act of sabotage, occurs in reiser4/jnode.c, where the order of 2 lines has been swapped. This:
[/quote]

I TEND TO AGREE WITH MORTON'S OBSERVATIONS AND TO BE ON HIS SIDE THIS TIME. IF SOMEONE WHO "CLAIMS" TO KNOW SO MUCH REISER4 IS THERE WHY THE HE** HE DOESN'T CONTACT MORTON AND HELP HIM WITH PUTTING REISER4 INTO THE KERNEL?! I'LL TELL YOU WHY:
BECAUSE IT'S EASIER TO SEE CONSPIRACIES AND TO SHOUT THEM OUT LOUD THAN REALLY DOING SOMETHING.

[hoho]

Just don't feed the trolls.

[Jade]

You see, the Reiser4 saboteurs arranged that plain Reiser4 will not work properly. However, they forgot to sabotage the more complex case of transparent compression, so we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.
This is an excellent point.

[lenrek]

Just don't feed the trolls.

Hey, what is the fun then? :D

[Jade]

Just don't feed the trolls.
What's a troll? This is a real question.

[some-guy]

Can this thread be closed, it is far too off-topic

[Jade]

Can this thread be closed, it is far too off-topic
If you don't like it, don't read it. Your choice.

You can't close threads because they go off topic,... otherwise you hand the liars/saboteurs the ability to close any and all threads they choose.

Why don't you open a thread in General Discussion (for Anything off-topic) to discuss whatever topic you feel should not be addressed here. Yes you should do that.

[some-guy]

What's a troll? This is a real question.
http://en.wikipedia.org/wiki/Troll_(Internet)

[Michael]

You can't close threads because they go off topic,... otherwise you hand the liars/saboteurs the ability to close any and all threads they choose.

Why don't you open a thread in General Discussion (for Anything off-topic) to discuss whatever topic you feel should not be addressed here. Yes you should do that.

More like I have decided that you are indeed just spewing bullshit in this thread and other sorts of spam. Therefore, this thread is being closed.