similar to: Shrink ext3 filesystem , running out of inode questions

I'm currently working with a testing system that involves running mkfs.ext3 on some pretty large devices on a regular basis. This is getting fairly painful, and I was wondering if there was some way to speed this up. Understood that the end result might be a filesystem that has less of a safety factor (say, fewer superblock backups) but the tradeoff might be worth it in this case. David

Hi, I am trying to find way to speed up read access on ext3 filesystem. I did some tests using dd, with different block sizes, directio and none, etc. The test file is about 1Gig in size, and spread across 25 fragments (found using filefrag). Block size is 4k. I have also tried setting readahead buffer using blockdev , from 256 to 32767. time /root/dd conv=nocreat ibs=4096 obs=4096

I installed CentOS on my home-server with 2 IDE 160GB MAXTOR HDD / RAID-1, LVM and ext3 partitions. Previous OS on this machine was FC2. I often "play" with LVM and, sometimes, have to extand or reduce some volumes size. I was surprised to see that resize2fs isn''t included anymore ! The replacing tool is ext2online but this one seems to only be able to grow a filesystem (not

Hi, I have a doubt if I use the mke2fs option the right way. I formatted two different disks, one with $ mke2fs -b 4096 -E stride=16 -m 1 -T news /dev/sdd and the other with $ mke2fs -b 4096 -E stride=16 -m 1 -T largefile4 /dev/sde sdd is supposed to get files between 8k and 16k. sde will handle files with a fixed size of 32Mb. Then I tried this : $ dd if=/dev/zero of=/mount-sdx/file bs=4k

Hi. I want to make a snapshot from a logical volume and noticed that there must be enough free disk space in the volume group. Actually there is no free disk space left. How do i shrink online /var without losing any data or restore from backup? I do not have physical access to the server. Specs: Dell PE SC1430 with a 5/i RAID Controller one RAID 1 array from the Dell RAID controller 2

All, I'm requesting comments from the expert readers of ext3-users on these notes for tuning ext3 for performance. Most helpful would be feedback pertinent to RHEL 5; as XFS isn't supported under Red Hat Enterprise Linux these items are an attempt to match XFS performance with ext3. These items were culled from a number of sources. Will they be effective for achieving the performance

Hi, I want to use an ext3 Partition (~1TB) for Mail Storage, this means tons of small files. Has anyone recommendations about blocksize, inodes, etc. for mkfs.ext3 ? Thanks in advance, David -- View this message in context: http://www.nabble.com/Ext3----which-blocksize-for-small-files--tf2601442.html#a7257363 Sent from the Ext3 - User mailing list archive at Nabble.com.

I've got a 3.3TB ext3 on a FC3 64-bit system, running kernel 2.6.10-1.766FC3smp. I create the partition with parted 1.6.21, and I make the fs via: mkfs.ext3 -m1 -b 4096 -T largefile4 /dev/sda1 Works fine. bonnie++ running on it multiple times for days on end, no problems. However, I do the exact same setup on a RHEL4-AS i686 system, 32-bit, and the fs is totally hosed, get all kinds of

Hi, We got a huge problem on our sun grid engine cluster with glusterfs 3.3.0. Could somebody help me? Based on my understanding, if a folder is removed and recreated on other client node, a program that tries to create a new file under the folder fails very often. We partially fixed this problem by "ls" the folder before doing anything in our command, however, Sun Grid Engine

Suppose I generate an integer vector with e.g. SEXP iv = PROTECT(allocVector(INTSXP, 100)); and later want to shrink the object, e.g. shrink(iv, 50); would simply re-set the length to 50, and allow R to reclaim the memory that was previously used. Is it possible to do this while respecting how R manages memory? The motivation: there are many operations where the length of the output

>Yes, if you are creating larger files. By default e2fsck assumes the average >file size is 8kB and allocates a corresponding number of inodes there. If, >for example, you are storing lots of larger files there (digital photos, MP3s, >etc) that are in the MB range you can use "-t largefile" or "-t largefile4" >to specify an average file size of 1MB or 4MB

(... to Nabble Ext3:Users - reposted by me after I joined the ext3-users mailing list - sorry for the dup...) A bit of a rambling subject there but I am trying to figure out if it is more efficient at runtime to have few very large file systems (8 TB) vs a larger number of smaller file systems. The file systems will hold many small files. My preference is to have a larger number of smaller file

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've already sent this message to Ted Ts'o directly. I should have sent it to this list first but I didn't know about it until today. My apologies to Ted.) Last Friday a system that I just inherited refused to mount a file system that had been working fine for about 6 months. This is on a Scientific Linux 4.3 system using a 2.6.9 kernel. This is another Linux distribution based on

I have numerous qcow2 images which need to be reduced in size and have their maximum size (virtual size) reduced. Physical disk space became so low that VMs "auto-paused" themselves, I moved enough images to solve the immediate problem but need to rectify the underlying issue. It seems that qcow[2] files are grown in size such that the data inside of them takes about 50-60% of the

I've got an approximately 100GB ext3 FS which we recently sized down from 300GB using e2fsadm (with the disc offline obviously). I noticed the following in dmesg the other day: EXT3-fs error (device lvm(58,8)): ext3_get_inode_loc: bad inode number: 14827639 EXT3-fs error (device lvm(58,8)): ext3_get_inode_loc: bad inode number: 14041793 EXT3-fs error (device lvm(58,8)): ext3_get_inode_loc:

Hullo! First mail, sorry if this is the wrong place for this kind of question. I realise this is a "piece of string" type question. tl;dr version: I have a resizefs shrinking an ext4 filesystem from ~4TB to ~3TB and it's been running for ~2 days. Is this normal? Strace shows lots of:- lseek(3, 42978250752, SEEK_SET) = 42978250752 read(3,

Hello, Thanks to "partner" on IRC who told me about this (quite big) problem. Apparently in a distributed setup once a brick fills up you start getting write failures. Is there a way to work around this? I would have thought gluster would check for free space before writing to a brick. It's very easy to test, I created a distributed volume from 2 uneven bricks and started to

hello: I have been reviewin my message slog and have found the following message: Dec 19 06:27:28 server02 kernel: EXT3-fs error (device sd(8,7)) in ext3_new_inode: error 28 What is error 28 and should I be worried about it? Ray Turcotte

Wow, it takes a really long time to make a 2TB ext2fs. Are there better-than-default options that could be used for a large filesystem? mke2fs 1.34 (25-Jul-2003) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 244203520 inodes, 488382016 blocks 24419100 blocks (5.00%) reserved for the super user First data block=0 14905 block groups 32768 blocks per group,