similar to: ext3 performance with hardware RAID5

I can't seem to get the read and write performance better than approximately 40MB/s on an ext2 file system. IMO, this is horrible performance for a 6-drive, hardware RAID 5 array. Please have a look at what I'm doing and let me know if anybody has any suggestions on how to improve the performance... System specs: ----------------- 2 x 2.8GHz Xeons 6GB RAM 1 3ware 9500S-12 2 x 6-drive,

New api mke2fs for full configuration of filesystem. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/ext2.c | 452 +++++++++++++++++++++++++++++++++++++++++ generator/generator_actions.ml | 18 ++ gobject/Makefile.inc | 6 +- src/MAX_PROC_NR | 2 +- 4 files changed, 475 insertions(+), 3 deletions(-) diff --git

We are having problems remounting an ext3 filesystem using an external journal device. The filesystem in question was working fine until the server was rebooted. This is what we see on dmesg when trying to mount: EXT3: failed to claim external journal device. The external journal lives on a LVM2 logical volume and it seems to be accessible ( we can dumpe2fs and see filesystem information).

Peter Kjellstr?m wrote: > On Monday 23 January 2006 16:46, Plant, Dean wrote: >> I need to downgrade a system from Centos x4.2 to v3.6 (x86) due to >> performance problems with Arkeia Network Backup and AIT-4 tape >> drives. The backup database is stored on a v4.2 created ext3 >> partition. When accessing this partition after the downgrade, Centos >> complains on

Hello, How to upgrade existing ext3 partition to new features? Moved from RHEL3 to RHEL4. I had to install from c0d0p6 so partition could not be reformated during install. Thanks, Mindaugas # dumpe2fs /dev/cciss/c0d0p1 | fgrep features dumpe2fs 1.35 (28-Feb-2004) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super # dumpe2fs

I created a filesystem as follows: mke2fs -j -O dir_index -O sparse_super -T largefile /dev/drbd/6 Here's the the output from df Filesystem Size Used Avail Use% /dev/drbd/6 475G 33M 452G 1% It seems that ext3 has taken 23 GB, which is about 5% of the total disk size, for itself. Is that right? If that is, indeed, the case, why does df just list 33M as being

i posted on rhel list about proper creating of 6tb ext3 filesystem and tuning here.......http://www.redhat.com/archives/nahant-list/2006-November/msg00239.html i am reading lots of ext3 links like...... http://www.redhat.com/support/wpapers/redhat/ext3/ http://lists.centos.org/pipermail/centos/2005-September/052533.html http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html ............but

I made a filesystem (mke2fs -j) on a logical volume under kernel 2.6.20 on a 64-bit based system, and when I try to mount it, ext3 complains with EXT3-fs: dm-1: couldn't mount because of unsupported optional features (80). I first thought I just forgot to make the filesystem, so I remade it and the error is still present. I ran fsck on this freshly made filesystem, and it completed with

(I'm not subscribed to the list: please keep me in CC) I'm copying files between two samba server using robocopy from a third Windows PC and i'm experiencing disk usage that is much higher on the destination PC. The origin samba server is Debian Lenny with samba 3.2.5. The destination samba server is Debian Wheezy with samba 3.6.9 The PC running robocopy is Windows Server 2003 with

Hopefully, someone can tell me if this is OK. I recently had a problem with my system and had to do a complete restore. Fortunately, I had made a full backup just the day before. My filesystems are Ext3 (why else would I be posting this here?). :) Anyway, when I originally changed my filesystems from Ext2 to Ext3, I did while they were still mounted. As a result, the journal file was visible.

On 10/02/2020 01:24, michael at chameleonoriginals.com wrote: > It is an EspressoBin v7, ext4 filesystem, Ubuntu 18.04.? I encountered > previous failures saying I needed POSIX ALCs enabled, so am using a > 4.4.52 kernel built from source with the EspressoBin required updates > and POSIX ACLs (ext3 and ext4) enabled. > > tune2fs reports > Filesystem features:?????

Hello, I have some performance problems in a file server system. It is used as Samba and NFS file server. I have some ideas what might cause the problems, and I want to try step by step. First I have to learn more about these areas. First I have some questions about tuning/sizing the ext3 journal. The most extensive list I found on ext3 performance tuning is

Hopefully this is a simple issue or just my ignorance on the results returned by "df -k" but can anyone explain why the available block is 0 if total 1k-blocks - Used is greater than 0? #df -k /ems/bigdisk/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg0-bigdisk 397367512 383562960 0 100% /<name> Filesystem volume

On Sun, 17 Dec 2023 20:16:23 -0500 Mark Foley via samba <samba at lists.samba.org> wrote: > on Sun Dec 17 12:15:28 2023 Rowland Penny via samba > <samba at lists.samba.org> wrote: > > > > On Sun, 17 Dec 2023 11:50:18 -0500 > > Mark Foley via samba <samba at lists.samba.org> wrote: > > > > > > Spindles7, Thanks. my cloning the

Hi Folks, I was wondering if anyone has an pointers/suggestions on how I might increase disk performance of a HVM zvol-backed DomU? - this is my first DomU, so hopefully its something obvious Running bonnie++ shows the DomU''s performance to be 3 orders of magnitude worse than Dom0''s, which itself is half as good as when not running xVM at all (see bottom for bonnie++ results)

Hello, Does anyone have experience using a 3ware 9650SE series raid controller on CentOS 6.0? I am getting very sporadic throughput with moderately sized files (0.5-2GB) on ext3. I have tried most of the mount time tuning options: * noatime * trying different journal types * setting commit=120 - helped a little Even after these optimizations it doesn't seem like the raid array is working

I run a decent amount of 3ware hardware, all under centos-4. There seems to be some sort of fundamental disagreement between ext3 and 3ware's hardware RAID5 mode that trashes write performance. As a representative example, one current setup is 2 9550SX-12 boards in hardware RAID5 mode (256KB stripe size) with a software RAID0 stripe on top (also 256KB chunks). bonnie++ results look

Hi, I have a program that writes lots of files to a directory tree (around 15 Million fo files), and a node can have up to 400000 files (and I don't have any way to split this ammount in smaller ones). As the number of files grows, my application gets slower and slower (the app is works something like a cache for another app and I can't redesign the way it distributes files into disk due

I have an ext3 filesystem that has several directories and each directory gets a large number of files inserted and then deleted over time. The filesystem is basically used as a temp store before files are processed. The issue is over time the directory scans get extremely slow even if the directories are empty. I have noticed the directories can range in size from 4k - 100M even when they are

SUMMARY We are getting many ``Free blocks count wrong for group'' errors when running e2fsck on a 245-GB ext3 filesystem. This is when the file system is cleanly unmounted on a relatively quiet system to do a resize. From reading other messages here, my suspicion is that this is because we have e2fsprogs 1.32. Questions: * Should we use e2fsck/e2fsprogs 1.36 and will that probably