Jehn Sanders | 3 Jul 2008 03:49
Picon

web site noticed

Dear Jfs-discussion,
Its time to get your web site noticed. We can increase your monthly web traffic and get you the best 
position on every major search engines (Eg: Google, Yahoo!, AOL, AltaVista, etc).   We would like to 
show you how with a free site review.  Email us today and we will do a no cost site assessment so that 
you can see for yourself what your online business could produce. 
Sincerely
Jehn Sanders
jehnsanders <at> gmail.com
________________________________________
K-Media Solutions
Yahoo!, Google, MSN, AltaVista, AOL
This promotion is only valid for USA websites

If you wish to be removed from this list, please reply the word "REMOVE" in your subject line

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
mobili | 4 Jul 2008 17:10

Bright and joyful Fourth of July

Well done 4th! http://66.176.38.218/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Melmi | 4 Jul 2008 23:15
Picon

"jfs clean" after failure, data corruption

Hi folks,

when my computer crashed last time, the jfs mounted drives claimed that the fs is "clean" on the next reboot.
However, some data was found in files were it didn't belong. My browser bookmarks, for example, went into
the configuration file of an email application (and therefore messed it up).

Now I'm wondering: 
When the computer just crashes, is it ok for jfs to call the fs "clean" on the next reboot?
How come that data moves into places it doesn't belong to?
Is there any chance to prevent such thing to happen?
Is there any chance to figure out which files have been corrupted so that the last backup may be used?

System is Debian Etch, to be honest in an sophisticated configuration;)
Partition 1, Software Raid, ReiserFS, mounted on /
Partition 2, Software Raid, CryptoFS, JFS, mounted on /cryptofs_mountpoint

Output from the first boot after the crash is below.

Thanks in advance for any information,

Melmi

Exerpt from Kernellog:
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: replayed 924 transactions in 11 seconds
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: Using r5 hash to sort names
Jul  2 07:35:36 playstation kernel: VFS: Mounted root (reiserfs filesystem) readonly.
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: Removing [71 7323 0x0 SD]..done
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: Removing [71 7321 0x0 SD]..done
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: Removing [71 7320 0x0 SD]..done
Jul  2 07:35:36 playstation kernel: ReiserFS: md1: Removing [71 7319 0x0 SD]..done
(Continue reading)

Michael Müller | 5 Jul 2008 11:57
Picon

Re: "jfs clean" after failure, data corruption

Hi Melmi.

Am 04.07.2008 um 23:15 schrieb Melmi:

> Hi folks,
>
> when my computer crashed last time, the jfs mounted drives claimed  
> that the fs is "clean" on the next reboot. However, some data was  
> found in files were it didn't belong. My browser bookmarks, for  
> example, went into the configuration file of an email application  
> (and therefore messed it up).
>
> Now I'm wondering:
> When the computer just crashes, is it ok for jfs to call the fs  
> "clean" on the next reboot?
> How come that data moves into places it doesn't belong to?
> Is there any chance to prevent such thing to happen?
> Is there any chance to figure out which files have been corrupted  
> so that the last backup may be used?
>
> System is Debian Etch, to be honest in an sophisticated  
> configuration;)
> Partition 1, Software Raid, ReiserFS, mounted on /
> Partition 2, Software Raid, CryptoFS, JFS, mounted on / 
> cryptofs_mountpoint
>
> Output from the first boot after the crash is below.
>
> Thanks in advance for any information,
>
(Continue reading)

Corey hardware | 5 Jul 2008 23:39

List of anesthesiologists and many more


The package below is valued at over $2000 when purchased individually

Licensed Physicians in the United States 

788,204 in total * 17,442 emails

Many different medical specialties

Over a dozen sortable fields

Database of US Pharma Companies
Personal email addresses (47,000 in total) and names for top level executives

Hospitals in America
Complete contact information for the important jobs held at the hospitals

US Dentist List
More than half a million listings [worth $499 alone!]

Directory of US Chiropractors
Over than 100k chiropractors practicing in the USA

Price for this week only =  
$391 for all 5 datasets

send email to:      peter.zipkin_md <at> hotmail.com

valid thru  July 11

(Continue reading)

Dave Kleikamp | 6 Jul 2008 22:18
Picon

Re: "jfs clean" after failure, data corruption

On Fri, 2008-07-04 at 23:15 +0200, Melmi wrote:
> Hi folks,
> 
> when my computer crashed last time, the jfs mounted drives claimed
> that the fs is "clean" on the next reboot. However, some data was
> found in files were it didn't belong. My browser bookmarks, for
> example, went into the configuration file of an email application (and
> therefore messed it up).

JFS doesn't journal data, just metadata, so if the configuration file
was very recently created, its metadata could be intact, but the file
data may have been lost, exposing whatever data was in the data blocks
previously.

> Now I'm wondering: 
> When the computer just crashes, is it ok for jfs to call the fs "clean" on the next reboot?

After it replays the journal, it will assume the file system is clean,
as long as no errors were seen.

You could run fsck -f to make sure there really are no errors in the
file system.

> How come that data moves into places it doesn't belong to?

Explained above (possibly).  The data itself isn't journaled, so newly
created files may have random data after a crash.

> Is there any chance to prevent such thing to happen?

(Continue reading)

Milanovic | 7 Jul 2008 13:01

The Mummy 3 movie bankrupt, release delayed

Cindy crawford ugly divorce details http://t-consulting.it/r.html

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
Peter Grandi | 6 Jul 2008 23:30
X-Face
Picon

Re: "jfs clean" after failure, data corruption


> JFS doesn't journal data, just metadata, so if the
> configuration file was very recently created, its metadata
> could be intact, but the file data may have been lost,
> exposing whatever data was in the data blocks previously.

>> Now I'm wondering: When the computer just crashes, is it ok
>> for jfs to call the fs "clean" on the next reboot?

> After it replays the journal, it will assume the file system
> is clean, as long as no errors were seen.

To make this more obvious: "clean" means that the *metadata* is
believed to be clean. The JFS code manages the integrity of the
metadata, the persistence of the data is the responsibility of
the applications (see below).

[ ... ]

> The data itself isn't journaled, so newly created files may
> have random data after a crash.

That's not quite right, as who writes this knows but is perhaps
too tired to add: newly created files that haven't been properly
committed by the application that created them may have random
data.

>> Is there any chance to prevent such thing to happen?

> Currrently no.
(Continue reading)

Dave Kleikamp | 7 Jul 2008 22:56
Picon

Re: "jfs clean" after failure, data corruption

On Sun, 2008-07-06 at 22:30 +0100, Peter Grandi wrote:
> > JFS doesn't journal data, just metadata, so if the
> > configuration file was very recently created, its metadata
> > could be intact, but the file data may have been lost,
> > exposing whatever data was in the data blocks previously.
> 
> >> Now I'm wondering: When the computer just crashes, is it ok
> >> for jfs to call the fs "clean" on the next reboot?
> 
> > After it replays the journal, it will assume the file system
> > is clean, as long as no errors were seen.
> 
> To make this more obvious: "clean" means that the *metadata* is
> believed to be clean. The JFS code manages the integrity of the
> metadata, the persistence of the data is the responsibility of
> the applications (see below).
> 
> [ ... ]
> 
> > The data itself isn't journaled, so newly created files may
> > have random data after a crash.
> 
> That's not quite right, as who writes this knows but is perhaps
> too tired to add: newly created files that haven't been properly
> committed by the application that created them may have random
> data.

It's possible that the application can do everything right, and a system
crash can still result in the metadata being committed before the data
is written to disk.
(Continue reading)

helen@nstnetwork.com | 9 Jul 2008 09:50

Sell Cisco Systems equipment items

Hello,
     We have following original Cisco,Card,GBIC/SFP,WIC,cables items for sale 
If you are interested, pls feel free to contact me.
example of the products:
CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm 
WS-G5483,
GLC-SX-MM
SFP-GE-L
WS-G5487,
WS-G5484,
WS-G5486,
GLC-SX-MM,
GLC-LH-SM,
GLC-ZX-SM,
GLC-T,
......
NM-2FE2W-T1,
NM-2FE2W-E1,
NM-2FE2W-V2,
WIC-1T,
WIC-2T,
WIC-2A/S,
WIC-1B/ST,
WIC-1ENET,
VWIC-1MFT-T1,
VWIC-1MFT-E1,
VWIC-2MFT-T1,
VWIC-2MFT-E1,
VWIC-1MFT-G703,
VWIC-2MFT-G703,
(Continue reading)


Gmane