World: r3wp

Which is %worlds/rebol3/chat19 for your old user.

Sorry, %worlds/rebol3/chat/19.set

Well.. we have a policy on our servers of *never* accessing any world's 
internal files for any reason. So, I had no idea something happened.

Checking for that file now, I see it does not exist!

That has to mean that the tar had some kind of problem.

I don't know how many groups we lost, but the world got a lot faster 
when it happened.

checking if the tar is still around

I was wondering why this world was so fast!

checking tar...

19 is in the tar.

19.set is 4.4mb!

right

you must chat a lot ;)

pm to self .. stop chatting

I can restore from tar any chats... but not so sure about merging... 
would need to think about that one a bit.

I suppose I could write a script to do a merge.

I wonder if this is the only world that had this problem?

It's all REBOL data, as long as no sequence number issues in the 
data model can trip things up.

That's the trick... the sync numbers.

Assuming it can be done, and that it would merge old and new PMs, 
does everyone here want it done?

Would do it next weekend. Let me know.

+1 from me (even though I have a full backup).

I can't speak for everyone, but yes please. Having the world fast 
is nice, but losing years of data has really shaken my faith in AltMe.

place faith in backups!

but backups can't be used in altme, so unless they are put back into 
the server, they are much less usefull.

for my self, I'd like to have the backup file directly, but not restored 
on the server... I had stopped PMs cause at 4.5 MB... slow... doesn't 
even begin to describe it.

In AltME, your local sync'd copy is supposed to be your backup.  
I did not know it would get deleted on a server problem. "Was not 
supposed to work that way."

(R3 Chat uses better method, and can use demand-based virtual msg 
entries to lower the overhead even more.)

+1 for restoring/merging old and new PMs

AltME uses a write/append which for some reason on Linux means: if 
you cannot append, truncate the entire file to zero.


For performance reasons (blame the early optimization guys), the 
default setting for many file systems on Linux is to write metadata 
independently from data, which means that it often gets written first. 
The result is that if writing the data fails (eg. power failure, 
kernel panic, ...), the files end up 0 length.


This can be disabled by setting the filesystem to always write data 
and metadata at the same time (at the price of write performance).

What filesystem is the AltME world server using? ext2 / ext3 ?

Gab, wow, interesting.

Good info Gab.  Anton ext3.

+1 Carl to restore altme data.

What ext3 journaling level did the server have?

Could one of our world masters please create a "!REBOL3 Proposals" 
group and put it under the R3 divider? Thanks.

Done.

(I don't seem to be able to position it under R3.....Perhaps it'll 
move whe it has some content)

yep... it just did.

Cancel that gripe.....I think it just took a while to resync and 
update the list.

....Or Maxim's dot worked magic.

ah... the magic dot.   ;-)

ok... so I am thinking loud.... should we switch  the new and old 
group namesÉ

since, as Brian noted, so far, most of the !REBOL  discussion has 
been about proposals, ideas and stuff?

oh.. I guess it would break up the [web-public] stuff  and any links 
to them.

Renaming groups should have no effect on either REBOL.org's or REBOL.net's 
links (both use the persistent group number rather than its name).


Taking a group from [web-public] to not web-public.....REBOL.net 
deletes the posts (that does break links). REBOL.org simply stops 
publishing newer posts. So all posts orginally [web-public] stay 
that way.

Carl: http://www.mjmwired.net/kernel/Documentation/filesystems/ext3.txt

data=ordered should be default on ext3 (not so on other fs though), 
but your distribution may be using writeback. or, what you have seen 
may have been due to something else. (personally i've often seen 
the 0 byte files on XFS after crashes, but never with ext3 or ext4)


There's also the fact that the fsync() semantics are not what most 
apps expect it to be, which turned into the filesystems trying to 
work around bad apps... and thus complexity.

This weekend (probably).....The 150,000th [web-public] post in this 
world:
    http://www.rebol.org/aga-groups-index.r?world=r3wp
It could be you!

it would be funny if it was a "." post.

What's the prize?

Who knows?
Maybe., eventually, a name check on REBOLweek.