Badoo | 19 Apr 10:00
Favicon

Milos rovcanin ti je poslao poruku...

Milos rovcanin ti je ostavio poruku...

Pošiljalac poruke i njen sadržaj biće vidljivi jedino tebi i možeš bilo kada da ih obrišeš. Takođe možeš trenutno na nju da odgovoriš uz pomoć messanger-a. Da saznaš šta piše u poruci, klikni na ovaj link:

Pročitaj poruku...


Neki ljudi iz okoline koji su na Badoo-u

Ivan
Beograd, Srbija
Saska
Beograd, Srbija
 
Sanela
Beograd, Srbija
 


Ovim i-mejlom dostavljamo poruku koju je na našem sistemu poslao korisnik Milos rovcanin. Ako ti je ovaj i-mejl stigao greškom, molimo te da ga jednostavno zanemariš. Poruka će u najkraćem roku biti uklonjena sa sistema.

Želimo ti dobar provod!
Badoo tim

Ovaj i-mejl je poslao Badoo Trading Limited (poštanska adresa ispod). Ukoliko više ne želiš da primaš Badoo obaveštenja i-mejlom, molimo te da klikneš ovde za odjavu.
Badoo Trading Limited je društvo sa ograničenom odgovornošću registrovano u Engleskoj i Velsu pod brojem 7540255 sa registrovanim sedištem na adresi: 12 Red Lion Square, London, WC1R 4QD.

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Favicon
Gravatar

Strange behaviour during file rename

http://stackoverflow.com/questions/9535653/file-rename-on-ext3-appears-to-break-posix-spec

 

I posted the above to stackoverflow – I am running a test does repeated file renames to a target file in one thread, and repeatedly reads that target file in another thread. This works fine except when there is a hard-link to the file being renamed to the target file. In this case the reading thread hits file not found errors (not always but often). This seems to break the sped for ‘rename’. 

 

The test is:

 

    #!/bin/bash

    touch target;

    for ((i=0; i < 1000; i=i+1)); do

        echo "snafu$i" > $1/file$i;

        ln $1/file$i $1/link$i

        mv -f $1/file$i $1/target;

    done;

 

and the reading side:

 

    #!/bin/bash

    while(true);do

        cat $1/target;

    done

 

if the linking step is removed from the writing thread, then no errors are seen as expected.

 

Does anyone know why the presence of the link causes read errors during the rename? I tried creating all the temporary files and links first, then pausing and then doing the rename loop – same erros are seen on the reading side.

 

Thanks.

 

This email has been sent by a member of the Man group (“Man”). Man’s parent company, Man Group plc, is registered in England and Wales (company number 2921462) at Riverbank House, 2 Swan  Lane, London, EC4R 3AD.
The contents of this email are for the named addressee(s) only. It contains information which may be confidential and privileged. If you are not the intended recipient, please notify the sender immediately, destroy this email and any attachments and do not otherwise disclose or use them. Email transmission is not a secure method of communication and Man cannot accept responsibility for the completeness or accuracy of this email or any attachments. Whilst Man makes every effort to keep its network free from viruses, it does not accept responsibility for any computer virus which might be transferred by way of this email or any attachments. This email does not constitute a request, offer, recommendation or solicitation of any kind to buy, subscribe, sell or redeem any investment instruments or to perform other such transactions of any kind. Man reserves the right to monitor, record and retain all electronic and telephone communications through its network in accordance with applicable laws and regulations. --UwQe9f5k7pI3vplngP

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Aaron Tomlin | 1 Jan 14:54
Picon
Favicon

Trace ACL updates to an ext3 inode

I am trying to record all ACL related updates to a particular inode on an ext3 file system.

Question:
  • Is ext3_set_acl() the best entry point to trace from?

I wrote the following trivial system tap script, in an attempt to capture this information:

#!/usr/bin/stap
/*
* Aggregate calls to ext3_set_acl() for a particular inode number
* Purpose:
*  - Track ACL modifications to an ext3 inode
*/
global check_count;
global inode_num = 0;

probe module("ext3").function("ext3_set_acl") {
        inode_num = $1;
        if ($inode->i_ino == $1) {
                printf ("execname: %s, pid: %d, inode num: %d\n", execname(), pid(), $inode->i_ino);
                /*check_count++; */
                check_count[execname()] <<< 1;
        }
}

probe end {
                printf ("Calls to ext3_set_acl():\n");
        foreach ([exec] in check_count-) {
                printf ("%s operated %d times on inode %d\n", exec, <at> count(check_count[exec]), inode_num);
        }
        delete check_count;
        delete inode_num;
}

Thanks in advance,
-- Aaron Tomlin
_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Badoo | 25 Dec 03:53
Favicon

Pročitaj poruku pre nego što bude obrisana!

Pročitaj poruku koju ti je poslao korisnik Milos rovcanin pre nego što bude obrisana!



Pročitaj poruku...


I još neki ljudi koji strpljivo čekaju:

Sebastian
Gent, Belgija
naomi
Gent, Belgija
 
Keke
Gent, Belgija
 


Ovim i-mejlom dostavljamo poruku koju je na našem sistemu poslao korisnik Milos rovcanin. Ako ti je ovaj i-mejl stigao greškom, molimo te da ga jednostavno zanemariš. Poruka će u najkraćem roku biti uklonjena sa sistema.

Želimo ti dobar provod!
Badoo tim

Ovim putem te obaveštavamo da ti je jedan Badoo korisnik poslao poruku na Badoo-u. Ovo je automatski generisana poruka i odgovori na nju se ne čuvaju niti čitaju. Ukoliko više ne želiš da primaš poruke iz Badoo-a, molimo te da nas obavestiš.

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Badoo | 17 Dec 10:01
Favicon

Milos rovcanin ti je poslao poruku...

Milos rovcanin ti je ostavio poruku...

Pošiljalac poruke i njen sadržaj biće vidljivi jedino tebi i možeš bilo kada da ih obrišeš. Takođe možeš trenutno na nju da odgovoriš uz pomoć messanger-a. Da saznaš šta piše u poruci, klikni na ovaj link:

Pročitaj poruku...


I još neki ljudi koji strpljivo čekaju:

Sebastian
Gent, Belgija
Jessica Herrebaut
Gent, Belgija
 
Leila
Gent, Belgija
 


Ovim i-mejlom dostavljamo poruku koju je na našem sistemu poslao korisnik Milos rovcanin. Ako ti je ovaj i-mejl stigao greškom, molimo te da ga jednostavno zanemariš. Poruka će u najkraćem roku biti uklonjena sa sistema.

Želimo ti dobar provod!
Badoo tim

Ovim putem te obaveštavamo da ti je jedan Badoo korisnik poslao poruku na Badoo-u. Ovo je automatski generisana poruka i odgovori na nju se ne čuvaju niti čitaju. Ukoliko više ne želiš da primaš poruke iz Badoo-a, molimo te da nas obavestiš.

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Markus Feldmann | 26 Nov 15:15
Picon
Picon

damaged encrypted LUKS device

Hi people,

i had created encrypted device with cryptsetup/LUKS which i setup with 
an ext4 filesystem. This device is an external USB harddisk. When i 
plugin this device it will be automatically mounted by my gnome3 system 
(Debian Wheezey/Testing), but this week i got an error. I did ask the 
ask the LUKS developers what is the problem and they told me that this 
is an ext4 problem.

The error message from gnome is:
> Einhängen von AIRY_1TB nicht möglich
>
> Error mounting: mount: wrong fs type, bad option, bad superblock on /dev/mapper/udisks-luks-uuid-70a2aedf-ce7e-4e12-8f0b-ec7974ebdbd4-uid1000,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so

And from <dmesg> i got the message:
> [ 3094.394043] EXT4-fs (dm-0): ext4_check_descriptors: Inode bitmap for group 3328 not in group (block 1235654634)!
> [ 3094.394056] EXT4-fs (dm-0): group descriptors corrupted!

Further on, when i try to <fsck -N /dev/sdb> i get:
> fsck from util-linux 2.19.1
> fsck: fsck.crypto_LUKS: not found
> fsck: Error 2 while executing fsck.crypto_LUKS for /dev/sdb

But cryptsetup is installed, only lvm2 is missing, but i dont have a LVM 
device and as i researched at "debian.org" there is no package which 
provides the command <fsck.crypto_LUKS>.

Any hints/instructions for me?

regards Markus

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Kristen Eisenberg | 5 Nov 14:06
Picon
Favicon

High CPU Utilization When Copying to Ext4

Sorry if this is not the correct mailing list for ext4 questions.

Kristen Eisenberg
Billige Flüge
Marketing GmbH
Emanuelstr. 3,
10317 Berlin
Deutschland
Telefon: +49 (33)
5310967
Email:
utebachmeier at
gmail.com
Site:
http://flug.airego.de - Billige Flüge vergleichen

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
ghoulsblade | 17 Oct 16:44
Gravatar

power outage turned raid ext3 into ext2, how to fix ?

Hi all,

after a power outage the raid5 /dev/md2 couldn't be assembled,
mdadm -Af (forced assemble) worked,
and i can access all the data when i mount it as ext2,
but it used to be ext3 before and i get errors trying to mount it as that.

after it couldn't be assembled directly (sorry, didn't save the original 
error message)
i found the right drives using
# mdadm --misc --examine /dev/sdX
and used
# mdadm -Af /dev/md2 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1 
/dev/sdi1
(-A assemble, f:forced) and it worked saying
# mdadm: forcing event count in /dev/sde1(0) from 51014 upto 51020
# mdadm: forcing event count in /dev/sdf1(1) from 51014 upto 51020
# mdadm: forcing event count in /dev/sdg1(2) from 51014 upto 51020
# mdadm: forcing event count in /dev/sdh1(3) from 51014 upto 51020
# mdadm: forcing event count in /dev/sdi1(4) from 51014 upto 51020

Now when i mount it (i only tried readonly for now) as ext2 it works 
fine, i can see the files etc,
but it used to be ext3, and when i try to mount it as that i get errors, 
so something is wrong.

mdadm --misc --examine reportet status clean and correct checksums (i 
checked before doing forced assemble)
smartctl -H on the physical drives reports they all pass the health-check
# mount -o ro -t ext2 /dev/md2 /media/mytest
works fine, after that umount and
# mount -o ro -t ext3 /dev/md2 /media/mytest
reports :
# mount: wrong fs type, bad option, bad superblock on /dev/md2,
#        missing codepage or helper program, or other error
#        In some cases useful info is found in syslog - try
#        dmesg | tail  or so

fsck.ext3 /dev/md2 reports :
# fsck.ext3 /dev/md2
# e2fsck 1.41.3 (12-Oct-2008)
# /dev/md2 contains a file system with errors, check forced.
# Pass 1: Checking inodes, blocks, and sizes
# Journal inode is not in use, but contains data.  Clear<y>?
#
# /dev/md2: e2fsck canceled.
#
# /dev/md2: ********** WARNING: Filesystem still has errors **********

where i cancelled to avoid ruining it.

any idea how to fix the error when mounting as ext3 ?
should i just run fsck.ext3 and tell it to clear journal stuff etc, or 
would that just remove the ext3 stuff and turn it into ext2 ?
Or is it a bigger mess and i should just use it as ext2 for the time being ?

Help appreciated =)
regards,
g
Andrey | 29 Sep 16:36
Picon

Re: ext3 with maildir++ = huge disk latency and high load

Let me to share some testing RAID 5 results with bonnie++:

ext3 (defaults,noatime):

Version  1.96       ------Sequential Output------ --Sequential Input- 
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
debian           2G   242  96 22458  10  8826   2  1854  98 120985  11 
317.1   3
Latency               211ms     896ms     720ms   22258us   18733us 
622ms
Version  1.96       ------Sequential Create------ --------Random 
Create--------
debian              -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16 12857  33 +++++ +++ 15377  34 13585  33 +++++ +++ 
15404  35
Latency             12284us     992us    1029us     432us     140us 
  76us

ext3 (-T small,defaults,noatime):

Version  1.96       ------Sequential Output------ --Sequential Input- 
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
debian           2G   229  98  4989   5  3862   1  1762  97 91111   9 
266.6   6
Latency             79046us   22858ms    2577ms   19253us   12120us 
767ms
Version  1.96       ------Sequential Create------ --------Random 
Create--------
debian              -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16  6422  16 +++++ +++ 10319  25  8934  21 +++++ +++ 
10347  26
Latency              9968us     977us     964us     482us     144us 
178us

ext3 (-T news,defaults,noatime):
Version  1.96       ------Sequential Output------ --Sequential Input- 
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
debian           2G   237  95 22807  11  8807   2  1897  99 121893  11 
324.6   5
Latency               223ms     808ms     523ms   13765us   11049us 
831ms
Version  1.96       ------Sequential Create------ --------Random 
Create--------
debian              -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16 12826  33 +++++ +++ 15900  35 14548  36 +++++ +++ 
15460  35
Latency               417us     984us    1024us     430us     140us 
175us

ext4 (defaults,noatime):

Version  1.96       ------Sequential Output------ --Sequential Input- 
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
debian           2G   256  98 21495   6  9896   2  1771  99 125775  11 
349.7   5
Latency             37738us     992ms    3490ms   10811us   12045us 
495ms
Version  1.96       ------Sequential Create------ --------Random 
Create--------
debian              -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16 14766  43 +++++ +++ 18026  46 16094  46 +++++ +++ 
17428  45
Latency               424us     982us    1023us     367us     139us 
174us

xfs(defaults,noatime,logbufs=8,logbsize=131072):

Version  1.96       ------Sequential Output------ --Sequential Input- 
--Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- 
--Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
/sec %CP
debian           2G   476  96 35129   9 12524   3  1417  99 124716  12 
445.9   9
Latency             19798us     420ms     721ms   14122us    9394us 
131ms
Version  1.96       ------Sequential Create------ --------Random 
Create--------
debian              -Create-- --Read--- -Delete-- -Create-- --Read--- 
-Delete--
               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 
/sec %CP
                  16  1552   8 +++++ +++  1705  11  1675   9 +++++ +++ 
1346   8
Latency               104ms     291us   48604us     109ms      45us 
227ms

It seems that latency is big in whole results, best is for XFS. It is 
tempting me to think that there are some RAID 5 issues here. It's really 
strange that block writing for SCSI server disks in RAID5 is no more 
than 30MB/sec(XFS). I guess I should consider XFS file system or 
different RAID configuration. May be someone can comment this strange 
benchmark result? Will very appreciate that.

With regards, Andrey.

23.09.2011 11:31, Janne Pikkarainen пишет:
> Hello,
>
> On 09/23/2011 08:51 AM, Andrey wrote:
>> Hello,
>>
>> I have a production mail server with maildir++ structure and about
>> 250GB (~10 millions) of files on the ext3 partition on RAID5. It's
>> mounted with noatime option. These mail server is responsible to local
>> delivery and storing mail messages.
>>
>> System has Debian Squeeze installed and Exim as MDA + Dovecot as
>> IMAP+POP3 server.
>>
>> Bonnie results are terrible. Sequential output for Block and Rewrite
>> are 10722ms and 9232ms. So if there is a 1000 messages in the mail
>> queue load is extremely high, delivery time is very big and server can
>> hang. I did not see such problems with UFS on FreeBSD server.
>>
>> As I understand ext3 file system is really bad for such configurations
>> with Maildir++ (many smaill files)? Is there a way to decrease disk
>> latency on ext3 or speed up it?
>>
>> With regards, Andrey
>>
>> ___
>

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Andrey | 23 Sep 11:52
Picon

Re: ext3 with maildir++ = huge disk latency and high load

Thank you for reply,

BTW, other webserver has almost the same bonnie results (10283ms and 
5884ms) on ext3 partition with 45GB of data (1.5 millions of files)?!

Hardware and RAID5(also hardware) are the same: HP Proliant DL380 G4 
with SmartArray 6i controller (as I see it comes with 128MB BBWC enabler 
but not kit).

I did not tried to mount fs with barriers disabled. Does it have any 
crititcal risks?

Bonnie tests was performed in the morning when we have a mininmal user load.

But why the same server with the same RAID(4 disks) but with FreeBSD+UFS 
was much better? I guess problem is in ext3 then?

With regards, Andrey.

23.09.2011 11:31, Janne Pikkarainen пишет:
> Hello,
>
> On 09/23/2011 08:51 AM, Andrey wrote:
>> Hello,
>>
>> I have a production mail server with maildir++ structure and about
>> 250GB (~10 millions) of files on the ext3 partition on RAID5. It's
>> mounted with noatime option. These mail server is responsible to local
>> delivery and storing mail messages.
>>
>> System has Debian Squeeze installed and Exim as MDA + Dovecot as
>> IMAP+POP3 server.
>>
>> Bonnie results are terrible. Sequential output for Block and Rewrite
>> are 10722ms and 9232ms. So if there is a 1000 messages in the mail
>> queue load is extremely high, delivery time is very big and server can
>> hang. I did not see such problems with UFS on FreeBSD server.
>>
>> As I understand ext3 file system is really bad for such configurations
>> with Maildir++ (many smaill files)? Is there a way to decrease disk
>> latency on ext3 or speed up it?
>>
>> With regards, Andrey
>>
>> ___
>
> (replying off-list, so the ext3 developers will not start a flamewar)
>
> In my opinion ext3 is a terrible file system for your kind of workload,
> especially if you have lots of concurrent clients accessing their
> mailboxes. Even though ext3 has evolved over the years and has gained
> features such as directory indexes, it still is not good for tens of
> million of frequently changing small files with lots of concurrency.
> Been there, done that, not gonna do it again. I administer servers with
> 50 000 - 100 000 user accounts, with couple of thousands active IMAP
> connections.
>
> Personally I switched from ext3 to ReiserFS many years ago and happily
> used it between 2004-2008, then after things went downhill from ReiserFS
> development point of view, I switched to XFS during a server hardware
> refresh. ReiserFS was excellent, but it really started to slow down if
> file system was more than 85% full and it also got fragmented over time.
>
> XFS has been rock-solid and fast since 2008 for me, but it has an
> achilles heel of its own: if I need to remove lots of files from a huge
> directory tree, the delete performance is quite sucky compared to other
> file systems. This has been improved in the later kernel versions with
> the new delaylog parameter, but how much, I've not yet tested.
>
> All this said, the performance of ext3 should not be THAT bad you are
> describing. Is the bonnie result done while the server is idle or while
> it has mail clients accessing it all the time? If you have hardware
> RAID, is there a battery-backed up write cache and are you sure it's
> enabled? Also, have you tried to mount your file system with barriers
> disabled? What kind of server setup you have?
>
> Something is very wrong.
>
> Best regards,
>
> Janne Pikkarainen
>
>

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
Andrey | 23 Sep 10:14
Picon

Fwd: Re: ext3 with maildir++ = huge disk latency and high load

23.09.2011 11:31, Janne Pikkarainen пишет:
Thank you for reply,

BTW, other webserver has almost the same bonnie results (10283ms and
5884ms) on ext3 partition with 45GB of data (1.5 millions of files)?!

Hardware and RAID5(also hardware) are the same: HP Proliant DL380 G4
with SmartArray 6i controller (as I see it comes with 128MB BBWC enabler
but not kit).

I did not tried to mount fs with barriers disabled. Does it have any
crititcal risks?

Bonnie tests was performed in the morning when we have a mininmal user load.

With regards, Andrey.

> Hello,
>
> On 09/23/2011 08:51 AM, Andrey wrote:
>> Hello,
>>
>> I have a production mail server with maildir++ structure and about
>> 250GB (~10 millions) of files on the ext3 partition on RAID5. It's
>> mounted with noatime option. These mail server is responsible to local
>> delivery and storing mail messages.
>>
>> System has Debian Squeeze installed and Exim as MDA + Dovecot as
>> IMAP+POP3 server.
>>
>> Bonnie results are terrible. Sequential output for Block and Rewrite
>> are 10722ms and 9232ms. So if there is a 1000 messages in the mail
>> queue load is extremely high, delivery time is very big and server can
>> hang. I did not see such problems with UFS on FreeBSD server.
>>
>> As I understand ext3 file system is really bad for such configurations
>> with Maildir++ (many smaill files)? Is there a way to decrease disk
>> latency on ext3 or speed up it?
>>
>> With regards, Andrey
>>
>> ___
>
> (replying off-list, so the ext3 developers will not start a flamewar)
>
> In my opinion ext3 is a terrible file system for your kind of workload,
> especially if you have lots of concurrent clients accessing their
> mailboxes. Even though ext3 has evolved over the years and has gained
> features such as directory indexes, it still is not good for tens of
> million of frequently changing small files with lots of concurrency.
> Been there, done that, not gonna do it again. I administer servers with
> 50 000 - 100 000 user accounts, with couple of thousands active IMAP
> connections.
>
> Personally I switched from ext3 to ReiserFS many years ago and happily
> used it between 2004-2008, then after things went downhill from ReiserFS
> development point of view, I switched to XFS during a server hardware
> refresh. ReiserFS was excellent, but it really started to slow down if
> file system was more than 85% full and it also got fragmented over time.
>
> XFS has been rock-solid and fast since 2008 for me, but it has an
> achilles heel of its own: if I need to remove lots of files from a huge
> directory tree, the delete performance is quite sucky compared to other
> file systems. This has been improved in the later kernel versions with
> the new delaylog parameter, but how much, I've not yet tested.
>
> All this said, the performance of ext3 should not be THAT bad you are
> describing. Is the bonnie result done while the server is idle or while
> it has mail clients accessing it all the time? If you have hardware
> RAID, is there a battery-backed up write cache and are you sure it's
> enabled? Also, have you tried to mount your file system with barriers
> disabled? What kind of server setup you have?
>
> Something is very wrong.
>
> Best regards,
>
> Janne Pikkarainen
>
>

_______________________________________________
Ext3-users mailing list
Ext3-users <at> redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Gmane