Reiser4

[nske]

CSI δεν έβλεπε;

 

Ναι, πώς, αφού αγόρασε και βιβλία για το πως αναλύει τα στοιχεία η αστυνομία σε εγκλήματα! ΤΟ κάρφωμα! :?

 

Κρίμα που το έκανε ή κρίμα που τον πιάσανε...

Αν το έκανε δεν είναι κρίμα που τον πίασανε φυσικά, το κρίμα είναι που το έκανε (αν το έκανε) τη στιγμή που ήταν διακεκριμένος επιστήμονας και OSS developer που θα μπορούσε να προσφέρει πολλά. Και βέβαια κρίμα για την γυναίκα και τα παιδιά του (αν και για κάποιον λόγο είμαι περισσότερο σοκαρισμένος με τον Reiser που τον "ήξερα" από τα emails του).

 

ΥΣ. Ξέρω ότι είμαι ζώο που το κάνω post αλλά δε μπορώ να αντισταθώ :oops:

 

 

ΥΣ2. BTW ένα σχόλιο στο Slashdot που με παραξένεψε:

 

They forgot to mention the most important piece of evidence in their arsenal: They reviewed the AOL search records that were released and identified record #456365 as likely to belong to Reiser, and noted many suspicious searches such as "I hate Nina Reiser" and "how to kill Nina Reiser without getting caught".

 

The most offensive part of this evidence of course is that Hans Reiser uses AOL Search....

 

Αφενός μου φαίνεται αδιανόητο κάποιος με την ιδιοφυία του Reiser να έκανε κάτι τέτοιο ηλίθιο και ανούσιο.

Αφετέρου.. Τέτοιο φακέλωμα πέφτει στην AOL;

[firewalker]

Δεν έχουν τον θεό τους... Μπορεί αν είναι δάκτυλος της Ms να τον παγίδευσαν για να μην ολοκληρώσει το έργο του. Πέρα από την πλάκα όμως ιδιαίτερα ευφυή άτομα παραλείπουν ή κάνουν πράγματα αδιανόητα σε εμάς.

[firewalker]

Τελικά τι απέγινε; Το reiserfs4 πάει;

[nske]

Σχετικά με την υπόθεση του Hans:

Initially Judge Julie Conger said that on Feb. 23 she would hold closing arguments and rule on whether there's enough evidence to order Hans Reiser to stand trial.[21] On Feb. 22 the closing arguments were postponed until March 9 because Reiser's attorney was involved with another unrelated trial which was running longer than expected.[22] On March 9, the judge ruled that Reiser would stand trial.[23] Reiser's arraignment was set for March 23.[24] On March 23 Reiser pleaded not-guilty before Judge C. Don Clay. The trial date was scheduled for June 11, but has moved again, this time until at least September.[25][26][27'][28]

Αυτοί είναι χειρότεροι κι από τους δικούς μας σε οργάνωση!

 

Για το reiser4, από ό,τι βλέπω στη λίστα υπάρχουν αρκετές δηλώσεις προβλημάτων και έχω την εντύπωση ότι η ανάπτυξη έχει επιβραδυνθεί σημαντικά με την απουσία του Hans Reiser. Εγώ πάντως δεν το χρησιμοποιώ πια γιατί φοβάμαι μη μείνω ξεκρέμαστος μετά από κάποιο update.

[firewalker]

Δεν γίνεται να μαζέψουμε υπογραφές και να τον αφήσουν να τελειώσει το project και μετά να τον στείλουν στην "καρέκλα";

[giorgosts]

http://www.wired.com/techbiz/people/.../ff_hansreiser

 

Ο Hans Reiser δίνει συνέντευξη από τη φυλακή όπου αναμένει δίκη, κατηγορούμενος για το φόνο της γυναίκας του.

 

Περίληψη προηγουμένων: O ανωτέρω είναι εφευρέτης και κύριος developer του ReiserFS, ένα filesystem ανοικτού κώδικα που έχει διαφορετικές αρχές λειτουργίας από τα υπόλοιπα, UNIX και μη. Για την εξέλιξη του συστήματος αυτού επιδοτήθηκε με $600.000 από το Αμερικανικό Πεντάγωνο, και προσέλαβε Ρώσους προγραμματιστές.

 

Γνώρισε τη γυναίκα του στη Ρωσία και την έκανε διευθύντρια την επιχείρησής του. Για να ενισχύσει τη ρευστότητα της επιχείρησης, πήρε δάνειο από τον επιστήθιο φίλο του που αποδείχτηκε αργότερα ότι ήταν σοδομαζοχιστής δολοφόνος κατά συρροή (serial killer). Είχε ήδη σκοτώσει οκτώ άτομα. Αυτός έκανε εξωσυζυγική σχέση με τη γυναίκα του, που αργότερα κατέληξε στη λύση του γάμου και σε μακρά δικαστική διαμάχη για την κηδεμονία των δύο παιδιών του ζεύγους. Η ψυχική υγεία του Reiser που ποτέ δεν ήταν καλή κατέρρευσε. Η αστυνομία μετά την εξαφάνιση της γυναίκας του τον παρακολούθησε για δύο εβδομάδες και βρήκε στο αυτοκίνητό του που το είχε κρυμμένο, το μπροστινό κάθισμα να λείπει, να είναι πλυμένο με πολλά νερά παντού, και μία σταγόνα αίμα που ταυτίστηκε με αυτό της γυναίκας του. (Επίσης δύο βιβλία, το ένα με θέμα το φόνο και το άλλο με θέμα την αυτοκτονία)

 

Συνελήφθη, τα παιδιά του τα πήρε η πρόνοια, μετά τα πήρε η μητέρα του Reiser, και μετά η άλλη γιαγιά από τη Ρωσία, η οποία στην αρχή είπε ότι ήταν για διακοπές, αλλά τώρα δεν τα γυρίζει πίσω.

 

Τέσσερις ημέρες μετά τη σύλληψή του η Novel ανακοίνωσε ότι το ReiserFS δεν θα είναι το προεπιλεγμένο filesystem στη διανομή SUSE.

 

Όποιος διαβάσει τη συνέντευξη θα δει πόσο αυτά που βλέπουμε στα θρίλερ και στις ταινίες τρόμου μπορεί να γίνουν στ' αλήθεια.

 

Ένα εύστοχο σχόλιο από τη σχετική συζήτηση στο Slashdot

 

And the wife doesn't sound like quite as much of a sweet, innocent victim anymore either. She started cheating on nutjob number 1 with even bigger nutjob number 2, the admitted murderer with bizarre sexual tastes, and exposed her children to that crap until a judge ordered her not to.

 

This is an admittedly fascinating story for some reason. But when you remember that it's all real, you can't help but shed a few tears for these kids, who are going to grow up with no mother, with a twisted father who probably killed their mother and will be rotting in jail for years to come, with a paranoid, delusional grandfather and kook for a grandmother in the US.

 

Maybe they're better off being in Russia after all. You come away from that story sort of despairing of their chances for growing up to be reasonably mentally healthy adults.

 

Και μία λεπτομέρεια: Μέσα στον (GPL) κώδικα του Reiser4 υπάρχει προσπάθεια του Reiser να εξηγήσει την προσωπική τραγωδία του με όρους λειτουργίας του filesystem και του λειτουργικού συστήματος:

 

open last dir/patch at ftp://ftp.namesys.com/pub/reiser4-for-2.6

Death is a complex process

 

file znode.c, item 5:

 

diff -puN /dev/null fs/reiser4/znode.c

--- /dev/null Thu Apr 11 07:25:15 2002

+++ 25-akpm/fs/reiser4/znode.c Wed Mar 30 14:55:08 2005

@@ -0,0 +1,1141 @@ /* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by

* reiser4/README */ /* Znode manipulation functions. */ /* Znode is the in-memory header for a tree node. It is stored

separately from the node itself so that it does not get written to

disk. In this respect znode is like buffer head or page head. We

also use znodes for additional reiser4 specific purposes:

 

. they are organized into tree structure which is a part of whole

reiser4 tree.

. they are used to implement node grained locking

. they are used to keep additional state associated with a

node

. they contain links to lists used by the transaction manager

 

Znode is attached to some variable "block number" which is instance of

fs/reiser4/tree.h:reiser4_block_nr type. Znode can exist without

appropriate node being actually loaded in memory. Existence of znode itself

is regulated by reference count (->x_count) in it. Each time thread

acquires reference to znode through call to zget(), ->x_count is

incremented and decremented on call to zput(). Data (content of node) are

brought in memory through call to zload(), which also increments ->d_count

reference counter. zload can block waiting on IO. Call to zrelse()

decreases this counter. Also, ->c_count keeps track of number of child

znodes and prevents parent znode from being recycled until all of its

children are. ->c_count is decremented whenever child goes out of existence

(being actually recycled in zdestroy()) which can be some time after last

reference to this child dies if we support some form of LRU cache for

znodes.

 

*/ /* EVERY ZNODE'S STORY

 

1. His infancy.

 

Once upon a time, the znode was born deep inside of zget() by call to

zalloc(). At the return from zget() znode had:

 

. reference counter (x_count) of 1

. assigned block number, marked as used in bitmap

. pointer to parent znode. Root znode parent pointer points

to its father: "fake" znode. This, in turn, has NULL parent pointer.

. hash table linkage

. no data loaded from disk

. no node plugin

. no sibling linkage

 

2. His childhood

 

Each node is either brought into memory as a result of tree traversal, or

created afresh, creation of the root being a special case of the latter. In

either case it's inserted into sibling list. This will typically require

some ancillary tree traversing, but ultimately both sibling pointers will

exist and JNODE_LEFT_CONNECTED and JNODE_RIGHT_CONNECTED will be true in

zjnode.state.

 

3. His youth.

 

If znode is bound to already existing node in a tree, its content is read

from the disk by call to zload(). At that moment, JNODE_LOADED bit is set

in zjnode.state and zdata() function starts to return non null for this

znode. zload() further calls zparse() that determines which node layout

this node is rendered in, and sets ->nplug on success.

 

If znode is for new node just created, memory for it is allocated and

zinit_new() function is called to initialise data, according to selected

node layout.

 

4. His maturity.

 

After this point, znode lingers in memory for some time. Threads can

acquire references to znode either by blocknr through call to zget(), or by

following a pointer to unallocated znode from internal item. Each time

reference to znode is obtained, x_count is increased. Thread can read/write

lock znode. Znode data can be loaded through calls to zload(), d_count will

be increased appropriately. If all references to znode are released

(x_count drops to 0), znode is not recycled immediately. Rather, it is

still cached in the hash table in the hope that it will be accessed

shortly.

 

There are two ways in which znode existence can be terminated:

 

. sudden death: node bound to this znode is removed from the tree

. overpopulation: znode is purged out of memory due to memory pressure

 

5. His death.

 

Death is complex process.

 

When we irrevocably commit ourselves to decision to remove node from the

tree, JNODE_HEARD_BANSHEE bit is set in zjnode.state of corresponding

znode. This is done either in ->kill_hook() of internal item or in

kill_root() function when tree root is removed.

 

At this moment znode still has:

 

. locks held on it, necessary write ones

. references to it

. disk block assigned to it

. data loaded from the disk

. pending requests for lock

 

But once JNODE_HEARD_BANSHEE bit set, last call to unlock_znode() does node

deletion. Node deletion includes two phases. First all ways to get

references to that znode (sibling and parent links and hash lookup using

block number stored in parent node) should be deleted -- it is done through

sibling_list_remove(), also we assume that nobody uses down link from

parent node due to its nonexistence or proper parent node locking and

nobody uses parent pointers from children due to absence of them. Second we

invalidate all pending lock requests which still are on znode's lock

request queue, this is done by invalidate_lock(). Another JNODE_IS_DYING

znode status bit is used to invalidate pending lock requests. Once it set

all requesters are forced to return -EINVAL from

longterm_lock_znode(). Future locking attempts are not possible because all

ways to get references to that znode are removed already. Last, node is

uncaptured from transaction.

 

When last reference to the dying znode is just about to be released,

block number for this lock is released and znode is removed from the

hash table.

 

Now znode can be recycled.

 

[it's possible to free bitmap block and remove znode from the hash

table when last lock is released. This will result in having

referenced but completely orphaned znode]

 

6. Limbo

 

As have been mentioned above znodes with reference counter 0 are

still cached in a hash table. Once memory pressure increases they are

purged out of there [this requires something like LRU list for

efficient implementation. LRU list would also greatly simplify

implementation of coord cache that would in this case morph to just

scanning some initial segment of LRU list]. Data loaded into

unreferenced znode are flushed back to the durable storage if

necessary and memory is freed. Znodes themselves can be recycled at

this point too.

 

*/

 

 

[headbanger]

diladi paei o diskos mu pu exw me reiserfs k 500gb data?na to kanw ext3 asap?oso prolavainw??

[nske]

Το reiserfs (3.6) είναι stable εδώ και αρκετά χρονιά, δεν άλλαξε τίποτα και εφόσον έχει συμπεριληφθεί στον επίσημο kernel δεν έχεις να φοβάσαι τίποτα.

[giorgosts]

Αν όμως βάλεις Reiser4 να ξέρεις ότι έχεις το χρονικό της τραγωδίας (κατά την άποψη του κατηγορούμενου) γραμμένο μέσα στο pc σου.

[gtroza]

Kernel space: two new filesystems for Linux

 

http://www.linuxworld.com/news/2007/062607-kernel.html

 

.