Re: Erratum
On November 17, 2005 08:13 pm, Leo Comerford wrote: > > - this is what comes of writing things in a hurry > Leo, As you may have noticed, I am working in this area right now. I'd like to read what you have written, but it's too long and jargon-laden for me to invest the time. Could you sum up everything you said into about a hundred words such that an educated layman could understand? I believe Einstein is quoted as saying "forgive the length of this letter, I did not have time to make it short" so please don't take this as a complaint about your idea, just about its presentation. -pvh -- Peter van Hardenberg ([EMAIL PROTECTED]) Victoria, BC, Canada
ZFS - Reiser team reactions?
Looks like ZFS is no longer vaporware. http://www.opensolaris.org/os/community/zfs/docs/ Any commentary from the Reiserfs team? A (supposedly) production ready FS that provides the transactions (using a similar/same tree ripple technique as reiser4), compression, and snapshotting, that we expected with reiser4 in the not two distant future... as well as checksumming, and raid integration (which uses checksumming to aid reconstruction) that we've barely just talked about here. People have already started asking about Linux integration, if it were not for that fact that CDDL is incompatible with the GPL, I'd expect it to make its way into linux before Reiser4 as well. A positive point is that this might be a good chance to point out that Reiser4 has some of ZFS's features already and is the right framework for building the rest (and much more)... and get some more interest in getting it merged and completed.
Hi
Hello, 3.99$ per tab = Gener:ic Sotfttabz Visiit us to buyy: http://www.sensitises.net/ Good Luck -- burrows symbiosis freebooters full-blooded vacuously curbs mountains flowery bluffing self-will shaft intercessions
Erratum
On 11/18/05, Leo Comerford <[EMAIL PROTECTED]> wrote: > $ setroot /(whatever)/friend/Ed This should be $ setroot /(whatever)/portrait/Ed - this is what comes of writing things in a hurry Leo. -- Leo Richard Comerford - http://www.st-and.ac.uk/~lrc1 - accept no namesakes :)
Re: File as a directory - file-as-dir vs. link-dirs (again) - 3/3
(This is the third and final choke-sized chunk. In order to keep any replies together, I suggest that people reply to this part unless the reply is very specific to one of the others.) File-as-dir is a flawed way of expressing parent-child relations. Unfortunately, when it comes to relations, expressing two-way parent-child links and providing a tree view of them is what file-as-dir does /best/. Even simple two-way relationships that don't have an obvious parent-child nature cause additional problems. Say we decided to create metadata to record which of the men are friends. So if Dean gets along with his brother Ed we could create /(something)/friend/aardvark: /(something)/friend/aardvark:1 (which is the file also known as '/(whatever)/portrait/Ed') /(something)/friend/aardvark:2 (which is the file also known as '/(whatever)/portrait/Dean') using link-directories. In fact, if we have anonymous last name segments, we can just create /(something)/friend/aardvark: , which links anonymously to both the Ed and Dean photos. But try to express this using subfiles: which of the two brothers will we arbitrarily choose to make the subfile of the other? In general, because the subfile relationship is always parent-child, to express a symmetric relationship in it we have to make up spurious extra data, declaring one participant in the relationship to be the 'parent' when no such distinction exists. Ed and Dean are unlikely to care about this, but try deciding whether Sales worksClosely with Marketing or Marketing worksClosely with Sales on your firm's computerised org chart. (Apparently things like LDAPisation projects have provoked wars over less.) And in the link-directory example using anonymous links, even the dumbest program that knows nothing about either /(something)/friends or friendship can tell that /(something)/friends/aardvark: is symmetric. In the link-directory example that doesn't use anonymous links, it doesn't know that - and subfile metadata will actively give it the false parent/child information. And of course even if we already know that a specific relationship is symmetric, or if it's not important that we find out, problems two and four from part two bite hard. For example, reliably finding all of Ed's friends' photos requires looking for both all his photo's ;friends children and all its ;friends parents every time. We have similar problems for relationships that aren't symmetric, but for which we don't want to have to declare one role to be the parent of the other. Which party in a is-husband-of/is-wife-of relation should be indicated as the parent? Then there are (>2)-way relations. Here's a good example of a three-way relation, lifted from the Rumbaugh-Blaha-Premerlani-Eddy-Lorensen OO book. Say that we have files representing programmers, software projects and programming languages. Now say that, for example, Bob is using Algol 68 on the Foomatic and both SNOBOL and PL/1 on Project Omega, while Dean is coding in PL/1 on the Computron and in PILOT on Project Omega, and Todd is formally specifying the Foomatic in Z. We would represent this information using link-directories by creating /(thingy)/impl-lang/aardvark:coder --> /(whatever)/portrait/Bob /(thingy)/impl-lang/aardvark:lang --> /bin/algol68 /(thingy)/impl-lang/aardvark:proj--> /(whatever)/projects/foomatic /(thingy)/impl-lang/zebra:coder --> /(whatever)/portrait/Dean /(thingy)/impl-lang/zebra:lang --> /bin/pilot /(thingy)/impl-lang/zebra:proj--> /(whatever)/projects/foomatic and so on: one link-directory for each triple of programmer, project and language. If we want to express the same information using subfile metadata we are going to have to create something like /(whatever)/portrait/Bob;impl-lang/1/proj --> /bin/algol68 /(whatever)/portrait/Bob;impl-lang/1/lang --> /(whatever)/projects/foomatic /(whatever)/portrait/Dean;impl-lang/1/proj --> /bin/pilot /(whatever)/portrait/Dean;impl-lang/1/lang --> /(whatever)/projects/foomatic and so on. Problem two is worse in this case. Not only do we have to look through the path"name"s of /(whatever)/projects/foomatic in order to find out what programmers are working on it, but in order to find out what languages Bob is using on the Foomatic we have to find the /(whatever)/portrait/Bob;impl-lang/* directories among the path"name"s of /(whatever)/projects/foomatic and then examine those directories' ./language names. And to find out what projects Bob is working on, we have to list all the /(whatever)/projects/* files which are linked from /(whatever)/portrait/Bob;impl-lang/*/project . All this is basically the same as working with link-directories using base-filesystem commands; indeed /(whatever)/portrait/Bob;impl-lang/1 is basically /(thingy)/impl-lang/aardvark: shoved under an arbitrary choice of one of the three files it relates. We created tools so that we could handle parent-child relations expressed as link-directories without clunkiness; naturally we can d
[2.6 patch] fs/reiser4/: possible cleanups
This patch contains the following possible cleanups: - make needlessly global code static - #if unused code away Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- fs/reiser4/estimate.c |2 +- fs/reiser4/flush_queue.c |2 ++ fs/reiser4/fsdata.c|9 ++--- fs/reiser4/fsdata.h|3 --- fs/reiser4/init_super.c|4 +++- fs/reiser4/inode.c |7 ++- fs/reiser4/jnode.c |2 ++ fs/reiser4/key.c |2 ++ fs/reiser4/key.h |1 - fs/reiser4/lock.c |3 +++ fs/reiser4/oid.c |2 ++ fs/reiser4/plugin/file/cryptcompress.c |4 fs/reiser4/plugin/file/file.h |3 --- fs/reiser4/plugin/plugin.c | 12 ++-- fs/reiser4/plugin/plugin.h |2 -- fs/reiser4/readahead.c |3 +++ fs/reiser4/readahead.h |1 - fs/reiser4/super.c |2 ++ fs/reiser4/super.h |4 fs/reiser4/tree.c |2 +- fs/reiser4/tree.h |2 -- fs/reiser4/tree_walk.c |4 fs/reiser4/tree_walk.h |2 -- fs/reiser4/znode.h |4 24 files changed, 43 insertions(+), 39 deletions(-) This patch contains the following possible cleanups: - make needlessly global code static - #if unused code away Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- fs/reiser4/flush_queue.c |2 ++ fs/reiser4/fsdata.c|9 ++--- fs/reiser4/fsdata.h|3 --- fs/reiser4/init_super.c|4 +++- fs/reiser4/inode.c |2 ++ fs/reiser4/jnode.c |2 ++ fs/reiser4/key.c |2 ++ fs/reiser4/key.h |1 - fs/reiser4/lock.c |3 +++ fs/reiser4/oid.c |2 ++ fs/reiser4/plugin/file/cryptcompress.c |4 fs/reiser4/plugin/file/file.h |3 --- fs/reiser4/plugin/plugin.c | 12 ++-- fs/reiser4/plugin/plugin.h |2 -- fs/reiser4/readahead.c |3 +++ fs/reiser4/readahead.h |1 - fs/reiser4/super.c |2 ++ fs/reiser4/super.h |4 fs/reiser4/tree.c |2 +- fs/reiser4/tree.h |2 -- fs/reiser4/tree_walk.c |4 fs/reiser4/tree_walk.h |2 -- fs/reiser4/znode.c |2 ++ fs/reiser4/znode.h |4 24 files changed, 44 insertions(+), 33 deletions(-) --- linux-2.6.14-rc5-mm1/fs/reiser4/flush_queue.c.old 2005-10-28 22:51:31.0 +0200 +++ linux-2.6.14-rc5-mm1/fs/reiser4/flush_queue.c 2005-10-28 22:57:29.0 +0200 @@ -644,6 +644,7 @@ INIT_LIST_HEAD(&atom->flush_queues); } +#ifdef REISER4_USE_EFLUSH /* get a flush queue for an atom pointed by given jnode (spin-locked) ; returns * both atom and jnode locked and found and took exclusive access for flush * queue object. */ @@ -707,6 +708,7 @@ return 0; } +#endif /* REISER4_USE_EFLUSH */ #if REISER4_DEBUG --- linux-2.6.14-rc5-mm1/fs/reiser4/fsdata.h.old2005-10-28 22:52:19.0 +0200 +++ linux-2.6.14-rc5-mm1/fs/reiser4/fsdata.h2005-10-28 22:54:19.0 +0200 @@ -135,8 +135,6 @@ extern void done_file_fsdata(void); extern reiser4_file_fsdata *reiser4_get_file_fsdata(struct file *); extern void reiser4_free_file_fsdata(struct file *); -extern reiser4_file_fsdata *create_fsdata(struct file *); -extern void free_fsdata(reiser4_file_fsdata *); /* @@ -182,7 +180,6 @@ extern int init_super_d_info(struct super_block *); extern void done_super_d_info(struct super_block *); -extern int file_is_stateless(struct file *); extern loff_t get_dir_fpos(struct file *); extern int try_to_attach_fsdata(struct file *, struct inode *); extern void detach_fsdata(struct file *); --- linux-2.6.14-rc5-mm1/fs/reiser4/fsdata.c.old2005-10-28 22:52:34.0 +0200 +++ linux-2.6.14-rc5-mm1/fs/reiser4/fsdata.c2005-10-28 22:54:41.0 +0200 @@ -18,6 +18,9 @@ /* spinlock protecting manipulations with dir_cursor's hash table and lists */ static spinlock_t d_lock = SPIN_LOCK_UNLOCKED; +static reiser4_file_fsdata *create_fsdata(struct file *file); +static int file_is_stateless(struct file *file); +static void free_fsdata(reiser4_file_fsdata *fsdata); static void kill_cursor(dir_cursor *); /** @@ -480,7 +483,7 @@ * one file system operation. This means that there may be "detached state" * for underlying inode. */ -int file_is_stateless(struct file *file) +static int fil
Re: File as a directory - file-as-dir vs. link-dirs (again) - 2/3
(This long essay has been posted in three parts. In order to keep any replies together, I suggest that people reply to the third part unless the reply is very specific to one of the others. This is part two, in which I criticise file-as-directory some more - far from exciting, but apparently still necessary. Things should pick up in part three.) But now let's try to express the father's/son's-photo relationships between the /(whatever)/portrait photos using subfile metadata instead of link-directories. /(whatever)/portrait/Mike is (the photo of) the father of (the man pictured in) /(whaterver)/portrait/Bob - how to express that using "files as directories"? We could decide that /(whatever)/portrait/Bob should have the additional path"name" /(whatever)/portrait/Mike/son-photo . But that would mangle the filesystem semantics: /(whatever)/portrait/Mike/son-photo isNotA /(whatever)/portrait/Mike . We need to distinguish the links from files to their "metadata files" from ordinary directory-to-directory and directory-to-file links. As the man said, don't try to make things simpler than possible. So let's call our new pathname /(whatever)/portrait/Mike;son-photo instead, where ';' is a "name" segment delimiter in the same way that '/' or (in my examples) ':' is. (Having a reserved segment-name like ..metas is an alternative implementation of the same idea.) Now this seems to work fairly well, but there are problems. Here are some of them. Problem one: We can assume that the partial pathname after the ';' , from the "file-as-directory" to the "metadata file", describes the type of relationship between the two files. So, for example, ';son-picture' describes one type of relationship, while others could be ';friend-picture', ';thumbnail' or ';social-sec-no'. So are all files in the same namespace as regards these relationship-names or not? In other words, if I see /(whatever)/foo;aardvark and /(something)/bar;aardvark , can I always safely assume that /(something)/bar;aardvark is to /(something)/bar as /(whatever)/foo;aardvark is to /(whatever)/foo ? If so, then there will be substantial risk of namespace collisions. So in practise, the "subfile" part of file"name"s will probably have to be fairly long-winded to minimise the risk: not ';foo' but ';something/not/altogether/unlike/a/third-party/java/package/name/foo' . If not, if there is some context in which I should interpret what ';aardvark' means, so that it can mean one thing for one "file-as-directory" and something else for another, what is that context and how can I know about it? Might it have something to do with the "file-as-directory"'s file type? (As defined how?) With one or more of the path"names" that the "file-as-directory" might have? By contrast, the type of a link-directory is defined by the predicate-directory it is a child of (by a non-opaque link). So the namespace of link-directory types is the same namespace of path"names" that all predicate-directories are in. Path"names" aren't necessarily very concise either, but at least we're not creating a second namespace, and equivalent path"name"s ought to be a lot shorter on average when you have pathname-listing and advanced searching on pathnames; for example, a user binary can have the two path"name"s /usr and /bin rather than one long path"name" /usr/bin. Problem two: consider that you discover Mike's photo-of-son by looking into its "subfiles" and seeing /(whatever)/portrait/Mike;son-photo , while you discover Bob's is-son-photo-of (in effect, its photo-of-father) by looking through its path"names" and also seeing /(whatever)/portrait/Mike;son-photo . To find all the relationships which a given file is involved in, you must check both its "subfiles" and its path"names". And whether a given relationship will be found among one or the other is arbitrary. Had we chosen to use ;father-photo rather than ;son-photo links, then Bob's metadata would have been a "subfile" while Mike's would have been a path"name". But, one could argue, this is only a problem in the special cases where both "directions" of a two-part relationship are worth expressing. It just so happens that the reverse of the is-son-of relation is a useful relation to consider. It just happens to be the case that every man is a father to all his sons; or rather, the reverse of 'x is the son of y' - 'y has the son x' - happens to be important enough to have another form, 'y is the father of x'. So in these special cases, we can create a link in both directions: for example, we can create both /(whatever)/portrait/Mike;son-photo and /(whatever)/portrait/Bob;father-photo . Then the user can find all of a file's useful file-is-dir metadata by inspecting its subfiles, and so happily ignore its subfile pathnames. But creating both /(whatever)/portrait/Mike;son-photo and /(whatever)/portrait/Bob;father-photo means having a cycle in the representation of some simple non-cyclic data. Also, the fact that Mike was the parent of Bob through a
Re: File as a directory - file-as-dir vs. link-dirs (again) - 1/3
Once again, I have to apologise for a stupidly long and stupidly late
reply. I've tried to make this thing a little more digestible by
chopping it into three chunks. In order to keep any replies together,
I suggest that people reply to the third part unless the reply is very
specific to one of the other parts. This first part is (I hope)
relatively fun.
First of all: I'll refer to 'relation-directories' as
'link-directories' from now on; the new term should be more
enlightening and less misleading. (Sorry if the change causes any
temporary confusion.) Again, each link-directory expresses one
instance of a relation; in RDB terms that's one tuple of a relation or
one row of a table, while in OO theory terms it's one link of a
relation. (In fact that's not completely and invariably true, because
of the "weakly-typed" nature of link-dirs.) The directory which (by
definition) has as its children every link-directory of a given type
is *not* a link-directory. (It is an ordinary predicate-directory.) In
RDB terms it is the table, and its children are its rows. In OO terms
it is the relation (which makes it a class) and its children are the
links of that relation (the objects which are instances of the
relation).
Second, in the coming examples, assume that the present working
"directory" can be set to any "name", those of ordinary atomic files
as well as those of link- and predicate-directories. This isn't
essential to anything that follows, but it does make things more tidy.
The ability to list the path"names" of a given file makes it useful to
have the pwd point to an atomic file: a command, say
$ ls -P
, can list (some of) the parents of the current file, whether or not
it is a directory. The change also creates consistency with
link-directories, which are non-(predicate-)directory files that can
be the target of the pwd.
On 5/28/05, Alexander G. M. Smith <[EMAIL PROTECTED]> wrote:
> Leo Comerford wrote on Wed, 18 May 2005 12:50:38 +0100:
> > But if you have relation-directories and the ability to find the
> > pathnames of a given file, you can do everything you can do with
> > subfiles, just as nicely, and more besides. And if subfiles are
> > completely redundant and bad news anyway, we shouldn't have them.
>
> I prefer subfiles (or fildirutes) as being easier to understand. But
> maybe that's just due to lots of experience with using file hierarchies.
> I can see having a relational system, but I'd always want to also have
> a directory hierarchy namespace, so that all files can be named.
>
> Having those relationship directories seems kind of clunky - since
> they're not located near the object being investigated. Though
> that's a GUI matter of making/(something)/friend the system file browser pop
> up a
> "Show Relationships..." menu item as contrasted with drilling down
> to a subfile directory listing by clicking on an item.
I'll start with an example here. Imagine a directory,
/(whatever)/portrait
, in which there are portrait photos of a number of men, one photo per
man. Each photo is identified under /(whatever)/portrait by the guy's
first name, so you have
/(whatever)/portrait/Mike
/(whatever)/portrait/Bob
and so on. Now suppose we use link-directories to express father/son
relationships between the guys in the photos. So, for example, if Mike
is Bob's father, we could have
/(something)/father-son/
/(something)/father-son/aardvark:
/(something)/father-son/aardvark:father (which is the file also known
as '/(whatever)/portrait/Mike')
/(something)/father-son/aardvark:son (the file also known as
'/(whatever)/portrait/Bob')
Using these link directories, we can easily express the information in
this (father's-side) family tree:
Mike
| |
v v
--- Bob -- Ted
|| | |
vv v v
Joe DeanEd Todd
, where Mike > Bob means "Mike is the picture of the father of the
guy pictured in Bob".
But this is where the clunkiness comes in. The family-tree
representation above is an obvious and natural way to conceive of and
manipulate the father/son relationships. We want there to be a
father-son link straight from Mike to Bob; what's more, we want to be
able to list the children (in the graph sense!) of Mike and see Bob
and Ted, and to move leafward from Mike to Bob or rootward from Bob to
Mike. But when we look at how we expressed the information using
link-directories, we see this instead:
--- /(something)/father-son/
| |
v v
aardvark -
Re: Reiser3 bug in 2.6.11.11
Konstantin Münning schrieb: init started and first system startup messages appeared. But then a bunch of oopses appeared fast so I was not able to find which part of the kernel was causing the first error and then the keyboard stops responding so I couldn't scrollback. At that point only powering down was possible. I can't tell if it happens while fs was RO or when/after it was remounted RW. And as there was no network or disk access at that point recovering some information was not possible. can you reproduce the oopses and redirect the errors/oops message to a serial console or netconsole? does the error go away with a current kernel? perhaps some reiserfs guru can decode them -- BOFH excuse #293: You must've hit the wrong any key.
Re: More Slowdown
Francesco Biscani schrieb:
What are the implications of doing something like this? Is "sync" going to
stop working or isn't it using this function?
sync(8) won't stop working, because it's using sync(2):
% strace -T sync 2>&1 | grep sync
execve("/bin/sync", ["sync"], [/* 20 vars */]) = 0
sync() = 0 <0.213305>
...but can someone explain to me: what's the difference between sync(2)
and fsync(2) ? why are there 2 systemcalls, why is fsync(2) expensive
and (mis?)used so often by applications and sync(2) is cheap (not?) and
used only by sync(8)? the manpages say:
fsync, fdatasync -
synchronize a file's complete in-core state with that on disk
sync -
commit buffer cache to disk
but both syscalls do not guarantee data integrity anyway, because
"modern disks have large caches".
thank you,
Christian.
--
BOFH excuse #453:
Spider infestation in warm case parts
Re: More Slowdown
6% fragmentation is enormous. You very much need the repacker we have not yet written. remember that one seek and rotate takes ~12 ms, and during that time you could transfer 50MB*.012 bytes. Hans John Gilmore wrote: >On Thursday 17 November 2005 12:40, Vladimir V. Saveliev wrote: > > >>Please try whether the attached patch improves anything. It simplifies >>fsync by avoid commiting of transactions which do not modify file being >>fsync-ed. >> >>The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. >> >> > >I haven't tried this patch yet, but I did try the earlier 'disable fsync >completely' patch. In fact, I'm using it right now. > >It doesn't help. Therefore, your patch probably won't help either. > >OK, disabling fsync does help a *little* bit. But I think that the issue (for >me, anyway) isn't sync per se, it's just flat-out access time. Deleteing lots >of small files is EXTREMELY slow, but even reading files is slower than it >should be. It took no less that 10 minutes to delete an old kernel source >tree, for instance. > >It's related to fragmentation, I think. I didn't really notice any speed >problems until my hard drive got to about 95% (or so) full. But they haven't >gone away, even though usage is now down around 54%. > >Hrm... I should be able to check that... > > >About an hour later... > >So maybe I was wrong. 6.5% data fragmentation doesn't seem that high. But >19.8% tree fragmentation does seem a bit high. > >How should this data be interpreted? > > >#measurefs.reiser4 -T /dev/mapper/e-h -f >measurefs.reiser4 1.0.5 >Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by >reiser4progs/COPYING. > >Tree fragmentation ... done >0.197747 > >#measurefs.reiser4 -S -D /dev/mapper/e-h -f >measurefs.reiser4 1.0.5 >Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by >reiser4progs/COPYING. > >Data fragmentation ... done >0.065593 >Tree statistics ... done >Packing statistics: > Formatted nodes:3721.29b (90.85%) > Branch nodes: 1734.57b (42.35%) > Twig nodes: 2886.97b (70.48%) > Leaf nodes: 3814.82b (93.14%) > >Node statistics: > Total nodes:8543553 > Formatted nodes: 146354 > Unformatted nodes: 8397199 > Branch nodes: 292 > Twig nodes: 10542 > Leaf nodes: 8532719 > >Item statistics: > Total items: 637352 > Nodeptr items: 146353 > Statdata items: 191218 > Direntry items: 17512 > Tail items: 245018 > Extent items: 36869 > > ># > > > >
Re: More Slowdown
PFC wrote: > > Just a few words about this "slowdown" thing. > > I use linux-2.6.11-cko1-swsusp2 with reiser4 included. I won't > upgrade to a new version until Hans says the current one is at least > as stable as it was before starting the merge... > > I get the "slowdown" once in a while, usually for 2-5 seconds, > it's not that annoying. > > However : > > If I understand well, when memory is needed (memory pressure), > reiser4 triggers a flush and writes dirty pages to the disk in large > quantities. > This has many advantages like not writing at all the temporary > files which already have been deleted, deferred allocation, etc, it's > really cool. > > However when "memory pressure" (ie. need to free some RAM) occurs, > it is usually that I am doing something interactively, like opening a > document or starting some software. Or it might mean that the > database server just received a big query which needs some sorting > space in RAM for instance. > Thus, "memory pressure" almost always means "I need memory NOW > and someone is waiting in front of their screen for it"... > And it is at this very moment that reiser4 has to flush (to free > memory). > Thus the "flush storm", by nature, always happens when you don't > want it to happen. It almost never happens when you are away from the > computer taking a leak, for instance. > > This is analogous to the problem caused to postgres by > checkpointing... the postgres guys implemented a background writer to > solve this. > I wonder if reiser4 could do the same, ie. trickle down dirty > pages to free up memory before it is actually needed, to improve > reactivity. There is a balance to be found, of course, between > flushing as late as possible (to benefit from all the nifty reiser4 > features) and flushing earlier (to avoid triggering the "flush storm"). > Maybe this could be set via a few controls... > - tell reiser4 to try to keep X amount of RAM immediately > available without flush > - when the CPU is idle, and/or when the disk is idle, start > flushing, but stop doing it as soon as some CPU is needed, or a key > is hit... > - just do frequent, small partial flushes which will keep good > locality of reference while being small > - do it at a lower priority so that the keyboard does not > stop responding !!! I agree that smoothness needs working on. After we merge. > > Huh, well, that's it... what do you think ? > > > >> When fsyncing, Reiser4, to my understanding, isn't allowed to put >> stuff in it's memory cache - it must put it to disk right away. And > > > This is the whole point of fsync, yes. > Now, it's pretty stupid for evlolution to issue a fsync() on every > pixel move or whatever. > fsync() is for databases or things which must survive a hard > system crash... > evolution could as well have used fflush() and everything would > have been alright. Dumb. > >> For comparative purposes, I hear of consumer systems with 2 or 4 GB of >> ram, and I know of brand new PC hard disks which have a throughput of >> less than 5 MB/s (my hard disk maxees out at 20 MB/s on my PC.) Do >> you know the throughputs of your drives, and the size of the memory in >> your machines? > > > Hum. A crap laptop harddrive will do 15 MBytes/s and a recent > normal desktop drive (7200rpm ATA or SATA) will do 50 MBytes/s or > more... > If you get a lot less (like, 5 MB/s), you have a problem (DMA > disabled, etc) > > > > PFC is right.
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Seems like there's a bug in your patch > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2-1.patch.gz [ cut here ] kernel BUG at fs/reiser4/block_alloc.c:149! invalid operand: [#1] last sysfs file: /class/vc/vcsa7/dev Modules linked in: snd_opl3_synth snd_seq_instr snd_seq_midi_emul snd_ainstr_fm snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_cmipci snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore ntfs tuner tvaudio bttv video_buf firmware_class i2c_algo_bit v4l2_common btcx_risc tveeprom i2c_core videodev ehci_hcd uhci_hcd usbcore via_rhine lp parport_pc parport loop aes_i586 nvidia rtc CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00210297 (2.6.14-mm2) EIP is at sub_from_ctx_grabbed+0x3b/0x50 eax: ebx: ecx: 0001 edx: esi: da564cc0 edi: c158d800 ebp: c5b6f2e0 esp: c3013ca4 ds: 007b es: 007b ss: 0068 Process java (pid: 7631, threadinfo=c3012000 task=c495ba90) Stack: 0001 c01a21ef da564cc0 0001 d36cf960 d36cf960 d3dd43e0 c01a428d d3dd43e0 0001 d36cf960 d36cf960 c5b6f38c c01a42ec d36cf960 d3dd43e0 c5b6f38c 0003 0001 c01d2f16 c5b6f38c Call Trace: [] grabbed2flush_reserved_nolock+0x3f/0x80 [] do_jnode_make_dirty+0x11d/0x150 [] jnode_make_dirty_locked+0x2c/0x40 [] save_static_sd+0x86/0x90 [] znode_make_dirty+0x1e/0x80 [] update_sd_at+0xd2/0x220 [] locate_inode_sd+0xe8/0x100 [] update_sd+0x7b/0xa0 [] preempt_point+0x5/0x20 [] write_sd_by_inode_common+0xc8/0xd0 [] init_context+0xe/0x80 [] sync_unix_file+0x58/0x80 [] write_file+0x9c/0xd0 [] preempt_point+0x5/0x20 [] txn_begin+0x1d/0x30 [] write_unix_file+0x310/0x5f0 [] copy_from_user+0x4c/0x90 [] write_unix_file+0x0/0x5f0 [] do_readv_writev+0x18d/0x310 [] schedule+0x313/0x650 [] vfs_writev+0x58/0x60 [] sys_writev+0x4b/0xb0 [] syscall_call+0x7/0xb Code: 24 14 8b 4c 24 10 8b 56 64 8b 46 60 39 da 76 15 29 c8 19 da 89 46 60 89 56 64 8b 1c 24 8b 74 24 04 83 c4 08 c3 72 04 39 c8 73 e5 <0f> 0b 95 00 32 8d 46 c0 eb db 8d 74 26 00 8d bc 27 00 00 00 00 - Regards, Thorsten
Re: Regular Plugin
Peter van Hardenberg wrote: The notion of the regular plugin seems odd to me. It is a seperate plugin type with distinct plugins that only serve to refer to "file" plugins (which are found in plugin/object.c, not in plugin/file/*.c). In accordance with the last policy file plugins, that implement objects which are known (for vfs) as regular files, should be stored in plugin/file directory, so in the latest versions of reiser4 the file regular.c has been moved to the upper common directory "plugin". So when I create a new "file" plugin, I cannot use it unless I also create a "regular" plugin which serves no purpose except to allow me to create those "file"s by storing their ID. You are right. A few words explaining why the "regular" plugin field couldn't have somehow storeda "file" plugin would be educational. Because changing a file plugin id is unsafe operation (at least in the case when there is more then one field of file plugin type in struct plugin_set): suppose you allow a some file plugin to be changed, it means that users also will be able to change foo//plugin/file, the main plugin which manages the file "foo". This is why we added a special plugin type: feel free to change these plugins. Also, regular is a rather unclear name. Something like "defaultfileplugin" might be easier to deduce, or even "defaultchild". Perhaps you are right about clearness, but the reason for the name "regular" was the need for nominated children to be "regular files for vfs". This is why "defaultfileplugin" sounds not so good (file plugin can be a directory file plugin, whereas mkdir doesnt look at this field at all, and "default" sounds like something that is not to be modified). Maybe "regularchild" will improve the situation? Thanks, Edward. -pvh
Re: More Slowdown or reiser4 update for 2.6.14-mm2
On Thursday 17 November 2005 18:22, Vladimir V. Saveliev wrote: > Hello > > Hesse, Christian wrote: > > Vladimir V. Saveliev wrote: > >>Please try whether the attached patch improves anything. It simplifies > >>fsync by avoid commiting of transactions which do not modify file being > >>fsync-ed. > >> > >>The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. > > > > Hi everybody, > > > > I'm suffering the same problem, sync and fsync are horribly slow. I've > > written a small test program: > > > > http://www.earthworm.de/tmp/reiser4-fsync.c > > > > with 2.6.13: > > sync() = 0 <0.000198> > > fsync(3)= 0 <0.003353> > > > > with 2.6.14 (with and without patch): > > sync() = 0 <2.092873> > > fsync(3)= 0 <0.132579> > > I tried your test on a box with reiser4 root fs: > 2.6.13: > strace -T -e sync,fsync ./eworm xx > fsync(3)= 0 <0.158808> > > 2.6.14-mm2 + > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2 >-1.patch.gz > > strace -T -e sync,fsync ./eworm xx > fsync(3)= 0 <0.005373> > > Would you please try whether 2.6.14-mm2 with fresh reiser4 update fsyncs > better? No change, still bad performance: up to 2 seconds in sync(), up to 0.2 seconds in fsync(). -- Christian pgpi42UtePgPN.pgp Description: PGP signature
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Me again, meanwhile I've applied this patch to my 2.6.14-mm2 (gentoo): ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2-1.patch.gz ...and I've got to say: THANK YOU! This patch has cured my slow system, everything's running normal again. Everything? Well, I'm not so sure about the result of the earthworm-test: $ strace -T -e sync,fsync ./a.out sync() = 0 <70.050916> fsync(3)= 0 <0.232150> Looks like a new world record of slowness. :-( Thorsten
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Hi again, > > http://www.earthworm.de/tmp/reiser4-fsync.c > > > > with 2.6.13: > > sync() = 0 <0.000198> > > fsync(3)= 0 <0.003353> > > > > with 2.6.14 (with and without patch): > > sync() = 0 <2.092873> > > fsync(3)= 0 <0.132579> > > I tried your test on a box with reiser4 root fs: > 2.6.13: > strace -T -e sync,fsync ./eworm xx > fsync(3)= 0 <0.158808> > > 2.6.14-mm2 + > ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2-1.patch.gz > > strace -T -e sync,fsync ./eworm xx > fsync(3)= 0 <0.005373> here are my results for 2.6.14-mm2 (gentoo, w/o that patch for -mm2): $ strace -T -e sync,fsync ./a.out sync() = 0 <0.767049> fsync(3)= 0 <0.207243> I'm going to install the latest gentoo-sources and will try it again with some patches. Oh, but please have a closer look onto the mail from John Gilmore, he wrote today. I'm experiencing the same: the slowdown does not affect vim and evolution only, but the whole system. And yes, also the reads are a lot slower. Bootup time has increased by factor 3 or 4. And because of all the disk activity I'd also guess, that some kind of fragmentation is causing these problems, but I haven't checked tree fragmentation, yet. ...probably later. Thorsten
Re: More Slowdown
On Thursday 17 November 2005 12:40, Vladimir V. Saveliev wrote: > Please try whether the attached patch improves anything. It simplifies > fsync by avoid commiting of transactions which do not modify file being > fsync-ed. > > The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. I haven't tried this patch yet, but I did try the earlier 'disable fsync completely' patch. In fact, I'm using it right now. It doesn't help. Therefore, your patch probably won't help either. OK, disabling fsync does help a *little* bit. But I think that the issue (for me, anyway) isn't sync per se, it's just flat-out access time. Deleteing lots of small files is EXTREMELY slow, but even reading files is slower than it should be. It took no less that 10 minutes to delete an old kernel source tree, for instance. It's related to fragmentation, I think. I didn't really notice any speed problems until my hard drive got to about 95% (or so) full. But they haven't gone away, even though usage is now down around 54%. Hrm... I should be able to check that... About an hour later... So maybe I was wrong. 6.5% data fragmentation doesn't seem that high. But 19.8% tree fragmentation does seem a bit high. How should this data be interpreted? #measurefs.reiser4 -T /dev/mapper/e-h -f measurefs.reiser4 1.0.5 Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by reiser4progs/COPYING. Tree fragmentation ... done 0.197747 #measurefs.reiser4 -S -D /dev/mapper/e-h -f measurefs.reiser4 1.0.5 Copyright (C) 2001, 2002, 2003, 2004 by Hans Reiser, licensing governed by reiser4progs/COPYING. Data fragmentation ... done 0.065593 Tree statistics ... done Packing statistics: Formatted nodes:3721.29b (90.85%) Branch nodes: 1734.57b (42.35%) Twig nodes: 2886.97b (70.48%) Leaf nodes: 3814.82b (93.14%) Node statistics: Total nodes:8543553 Formatted nodes: 146354 Unformatted nodes: 8397199 Branch nodes: 292 Twig nodes: 10542 Leaf nodes: 8532719 Item statistics: Total items: 637352 Nodeptr items: 146353 Statdata items: 191218 Direntry items: 17512 Tail items: 245018 Extent items: 36869 #
Re: More Slowdown or reiser4 update for 2.6.14-mm2
Hello Hesse, Christian wrote: > Vladimir V. Saveliev wrote: >>Please try whether the attached patch improves anything. It simplifies >>fsync by avoid commiting of transactions which do not modify file being >>fsync-ed. >> >>The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. > > Hi everybody, > > I'm suffering the same problem, sync and fsync are horribly slow. I've > written > a small test program: > > http://www.earthworm.de/tmp/reiser4-fsync.c > > with 2.6.13: > sync() = 0 <0.000198> > fsync(3)= 0 <0.003353> > > with 2.6.14 (with and without patch): > sync() = 0 <2.092873> > fsync(3)= 0 <0.132579> I tried your test on a box with reiser4 root fs: 2.6.13: strace -T -e sync,fsync ./eworm xx fsync(3)= 0 <0.158808> 2.6.14-mm2 + ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.14-mm2/reiser4-for-2.6.14-mm2-1.patch.gz strace -T -e sync,fsync ./eworm xx fsync(3)= 0 <0.005373> Would you please try whether 2.6.14-mm2 with fresh reiser4 update fsyncs better?
Re: need opinions from sysadmins on where reiser4progs should install
Hello Hans, On Sat, 12 Nov 2005 23:17:37 -0800 Hans Reiser <[EMAIL PROTECTED]> wrote: | What do the sysadmins on the list think? | | Hans Personally, for Reiserfs V3, i always compiled reiserfsprogs statically and installed the tools in /sbin. Mainly because, we used to have /usr on a separate partition on all server installs. So should a crash occur and /usr becomes corrupted, well, at least / is mounted and i could reiserfsck partitions right away, handy when the server is several thousand kilometers away :) I expect to do the same for reiser4progs, so i wish that reiser4progs utilities would install in /, and as such /sbin seems the best choice _to me_ Thanks Philippe PS: I hope that Santa will bring me a brand new kernel.org kernel with reiser4 in :) Good luck with that, and congratulations to you and the whole team for such a nice filesystem
Re: More Slowdown
Vladimir V. Saveliev wrote: > Please try whether the attached patch improves anything. It simplifies > fsync by avoid commiting of transactions which do not modify file being > fsync-ed. > > The patch applied to 2.6.14-mm2 with warnings, but that can be ignored. Hi everybody, I'm suffering the same problem, sync and fsync are horribly slow. I've written a small test program: http://www.earthworm.de/tmp/reiser4-fsync.c with 2.6.13: sync() = 0 <0.000198> fsync(3)= 0 <0.003353> with 2.6.14 (with and without patch): sync() = 0 <2.092873> fsync(3)= 0 <0.132579> -- Christian pgpyj0k35mBC3.pgp Description: PGP signature
Thomas: to you
L C A V X V Pe I m I a A rv A b A n L oi L i G a I zt I e R x U ara S n A M c 3,75 3,32 1,22 http://www.kfdrvt.renonendo.com
Re: More Slowdown
Hello
Artur Makówka wrote:
> Hans Reiser wrote:
>> fsync can be dramatically better optimized, and it will be after the
>> kernel merge work is completed. This optimization will likely consist
>> of reducing the tendency to merge atoms and handling fsync by using
>> write twice algorithms to a fixed journal area. Other improvements will
>> doubtless be found when time is spent on it. I am sorry that vim and
>> evolution are suffering so much from our neglecting fsync until after
>> the merge. fsync is one of the things I would have us working on if I
>> had my choice of what we improved in reiser4 rather than other persons
>> making that choice for us at the moment. Oh well, such is life in the
>> society of men.;-)
>>
>> It looks like akpm is going to start reading the reiser4 code. I
>> suspect his remarks will be a step above the ones made so far, he wrote
>> such nice readahead code.
>>
>
> Just want to add, that for desktop systems its only vim and evolution,
> but for my free hosting server it was very frequent system crashes
> (because of that i lost part of my database) and so on. Just want to
> warn anyone deciding to use reiser4 on server, to use 2.6.12 kernels or
> lower as this bug is almost not existent there.
>
> For some uses of reiser4 this bug is very dangerous. Not just slow work
> of some application, but like i said data loss, system instability (few
> crashes every day), and so on.
>
> I would say such a bug/design choice should be top priority, number one.
> Of course thats not true if reiser4 is meant to be only for home use.
> Just want to point that out, because it seems everybody is using reiser4
> only at home, and i am the only one on earth using it on server
> environment (i guess that wasn't the best idea...)
>
> Thanks in advance for consideration of taking this bug to top of your
> TODO list.
>
Please try whether the attached patch improves anything. It simplifies fsync by
avoid commiting of transactions which do not modify file being fsync-ed.
The patch applied to 2.6.14-mm2 with warnings, but that can be ignored.
This patch simplifies reiser4's fsync.
It is an experimental patch to test whether it helps against slowdowns reported
by users.
fs/reiser4/plugin/file/file.c | 14 ++
fs/reiser4/txnmgr.c | 22 +++---
fs/reiser4/txnmgr.h |1 +
3 files changed, 30 insertions(+), 7 deletions(-)
diff -puN fs/reiser4/plugin/file/file.c~reiser4-fix-fsync
fs/reiser4/plugin/file/file.c
--- linux-2.6.14-mm2/fs/reiser4/plugin/file/file.c~reiser4-fix-fsync
2005-11-17 13:42:26.0 +0300
+++ linux-2.6.14-mm2-vs/fs/reiser4/plugin/file/file.c 2005-11-17
13:42:26.0 +0300
@@ -1633,11 +1633,25 @@ int sync_unix_file(struct file *file, st
{
int result;
reiser4_context *ctx;
+ txn_atom *atom;
+ reiser4_block_nr reserve;
ctx = init_context(dentry->d_inode->i_sb);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
+ reserve = estimate_update_common(dentry->d_inode);
+ if (reiser4_grab_space(reserve, BA_CAN_COMMIT))
+ return RETERR(-ENOSPC);
+ write_sd_by_inode_common(dentry->d_inode);
+
+ atom = get_current_atom_locked();
+ spin_lock_txnh(ctx->trans);
+ force_commit_atom(ctx->trans);
+ reiser4_exit_context(ctx);
+ return 0;
+
+
assert("nikita-3486", ctx->trans->atom == NULL);
result = commit_file_atoms(dentry->d_inode);
assert("nikita-3484", ergo(result == 0, ctx->trans->atom == NULL));
diff -puN fs/reiser4/txnmgr.c~reiser4-fix-fsync fs/reiser4/txnmgr.c
--- linux-2.6.14-mm2/fs/reiser4/txnmgr.c~reiser4-fix-fsync 2005-11-17
13:42:26.0 +0300
+++ linux-2.6.14-mm2-vs/fs/reiser4/txnmgr.c 2005-11-17 13:42:26.0
+0300
@@ -1173,9 +1173,14 @@ static int commit_current_atom(long *nr_
/* TXN_TXNH */
-/* commit current atom and wait commit completion; atom and txn_handle should
be
- * locked before call, this function unlocks them on exit. */
-static int force_commit_atom_nolock(txn_handle * txnh)
+/**
+ * force_commit_atom - commit current atom and wait commit completion
+ * @txnh:
+ *
+ * Commits current atom and wait commit completion; current atom and @txnh have
+ * to be spinlocked before call, this function unlocks them on exit.
+ */
+int force_commit_atom(txn_handle *txnh)
{
txn_atom *atom;
@@ -1188,14 +1193,17 @@ static int force_commit_atom_nolock(txn_
assert("zam-834", atom != NULL);
assert_spin_locked(&(atom->alock));
- /* Set flags for atom and txnh: forcing atom commit and waiting for
-* commit completion */
+ /*
+* Set flags for atom and txnh: forcing atom commit and waiting for
+* commit completion
+*/
txnh->flags |= TXNH_WAIT_COMMIT;
atom->flags |= ATOM_FORCE_COMMIT;
spin_unlock_txnh(txnh);
spin_unlock_atom(atom);
+ /* c
Re: reiserfsck --rebuild-tree failure
Hi, On Nov/17/2005, Vitaly Fertman wrote: > > i've got a lot of error massages in kern.log: kern.log. > > obvious, there are badblocks: badblocks.log. > > check out www.namesys.com/bad-block-handling.html interesting, I didn't know this feature. It works in Reiser 3 and 4? (It seems that yes, just to be sure) -- Carles Pina i EstanyGPG id: 0x8CBDAE64 http://pinux.info Manresa - Barcelona
Re: More Slowdown
Hans Reiser wrote: fsync can be dramatically better optimized, and it will be after the kernel merge work is completed. This optimization will likely consist of reducing the tendency to merge atoms and handling fsync by using write twice algorithms to a fixed journal area. Other improvements will doubtless be found when time is spent on it. I am sorry that vim and evolution are suffering so much from our neglecting fsync until after the merge. fsync is one of the things I would have us working on if I had my choice of what we improved in reiser4 rather than other persons making that choice for us at the moment. Oh well, such is life in the society of men.;-) It looks like akpm is going to start reading the reiser4 code. I suspect his remarks will be a step above the ones made so far, he wrote such nice readahead code. Just want to add, that for desktop systems its only vim and evolution, but for my free hosting server it was very frequent system crashes (because of that i lost part of my database) and so on. Just want to warn anyone deciding to use reiser4 on server, to use 2.6.12 kernels or lower as this bug is almost not existent there. For some uses of reiser4 this bug is very dangerous. Not just slow work of some application, but like i said data loss, system instability (few crashes every day), and so on. I would say such a bug/design choice should be top priority, number one. Of course thats not true if reiser4 is meant to be only for home use. Just want to point that out, because it seems everybody is using reiser4 only at home, and i am the only one on earth using it on server environment (i guess that wasn't the best idea...) Thanks in advance for consideration of taking this bug to top of your TODO list.
Re: reiserfsck --rebuild-tree failure
On Wednesday 16 November 2005 20:27, iv wrote: > i'm following an advice to send a bug report about failed reiserfsck > --rebuild-tree found at http://www.namesys.com/faq.html#rebuild-tree. > i tried to compile the newest reiserfsprogs-3.6.15-pre1 but it fails use reiserfsprogs-3.6.19.tar.gz from ftp.namesys.com/pub/reiserfsprogs/ please > while doing "make": make.log. > so i run reiserfsck from a package (reiserfsck 3.6.13-pre1 (2003 > www.namesys.com)). it also failed: fsck.log. > i've got a lot of error massages in kern.log: kern.log. > obvious, there are badblocks: badblocks.log. check out www.namesys.com/bad-block-handling.html > i still can read from damaged partition. when i run `strings /dev/hdc3` > i get plently of text. > the question is if there is a way to mount the partition. > thanks in advance. > ivan matviyuk. > > -- Vitaly
Re: Reiser3 bug in 2.6.11.11
Hi! [EMAIL PROTECTED] wrote: > Konstantin Münning schrieb: > >> init started and first system startup messages appeared. But then a >> bunch of oopses appeared fast so I was not able to find which part of >> the kernel was causing the first error and then the keyboard stops >> responding so I couldn't scrollback. At that point only powering down >> was possible. I can't tell if it happens while fs was RO or when/after >> it was remounted RW. And as there was no network or disk access at that >> point recovering some information was not possible. > > > can you reproduce the oopses and redirect the errors/oops message to a > serial console or netconsole? does the error go away with a current > kernel? perhaps some reiserfs guru can decode them Sorry I had no time to play as it is an "in-production" laptop and had to be functional fast so I currently have no way to reproduce the fault. Redirecting output would require another kernel and the device has no serial or network port :-(. Maybe extracting metadata (debugreiserfs -p) would have been good for debugging but at that point I had nowhere to store it. If this happens a second time I will find a way to save it. As there were only a few fs errors reported by fsck probably looking over range/overflow checks in the code regarding used space/block size might give a hint... Have a nice day, -- Konstantin Münning
Re: More Slowdown
Just a few words about this "slowdown" thing. I use linux-2.6.11-cko1-swsusp2 with reiser4 included. I won't upgrade to a new version until Hans says the current one is at least as stable as it was before starting the merge... I get the "slowdown" once in a while, usually for 2-5 seconds, it's not that annoying. However : If I understand well, when memory is needed (memory pressure), reiser4 triggers a flush and writes dirty pages to the disk in large quantities. This has many advantages like not writing at all the temporary files which already have been deleted, deferred allocation, etc, it's really cool. However when "memory pressure" (ie. need to free some RAM) occurs, it is usually that I am doing something interactively, like opening a document or starting some software. Or it might mean that the database server just received a big query which needs some sorting space in RAM for instance. Thus, "memory pressure" almost always means "I need memory NOW and someone is waiting in front of their screen for it"... And it is at this very moment that reiser4 has to flush (to free memory). Thus the "flush storm", by nature, always happens when you don't want it to happen. It almost never happens when you are away from the computer taking a leak, for instance. This is analogous to the problem caused to postgres by checkpointing... the postgres guys implemented a background writer to solve this. I wonder if reiser4 could do the same, ie. trickle down dirty pages to free up memory before it is actually needed, to improve reactivity. There is a balance to be found, of course, between flushing as late as possible (to benefit from all the nifty reiser4 features) and flushing earlier (to avoid triggering the "flush storm"). Maybe this could be set via a few controls... - tell reiser4 to try to keep X amount of RAM immediately available without flush - when the CPU is idle, and/or when the disk is idle, start flushing, but stop doing it as soon as some CPU is needed, or a key is hit... - just do frequent, small partial flushes which will keep good locality of reference while being small - do it at a lower priority so that the keyboard does not stop responding !!! Huh, well, that's it... what do you think ? When fsyncing, Reiser4, to my understanding, isn't allowed to put stuff in it's memory cache - it must put it to disk right away. And This is the whole point of fsync, yes. Now, it's pretty stupid for evlolution to issue a fsync() on every pixel move or whatever. fsync() is for databases or things which must survive a hard system crash... evolution could as well have used fflush() and everything would have been alright. Dumb. For comparative purposes, I hear of consumer systems with 2 or 4 GB of ram, and I know of brand new PC hard disks which have a throughput of less than 5 MB/s (my hard disk maxees out at 20 MB/s on my PC.) Do you know the throughputs of your drives, and the size of the memory in your machines? Hum. A crap laptop harddrive will do 15 MBytes/s and a recent normal desktop drive (7200rpm ATA or SATA) will do 50 MBytes/s or more... If you get a lot less (like, 5 MB/s), you have a problem (DMA disabled, etc)
Re: More Slowdown
If you are frequently hit by fsync (as some of the previosly posters told us) an option might be to say something as tmgr.atom_max_age=30 (or tmgr.atom_max_size=?) in fstab (or remount the drive in vulnerable situations). Of course that sacrifices large parts of reiser4's mean performance, but that might be better than a largely unusable machine. One day reiser4 will be fully optimized. On 2005-11-16 22:08, michael chang wrote: > That would explain any > jerkiness -- it's because Reiser4 is writing everything from the last > real write to the actual disk to now (the current real right) in one > go, and making everything wait. -- Ingo Bormuth, voicebox & telefax: +49-12125-10226517 '(~o-o~)' public key 86326EC9, http://ibormuth.efil.de/contact ---ooO--(.)--Ooo---
