similar to: FC5: "ext_attr" and "large_file" features for ext3 file systems ???

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

I've Found a page with interesing discussion about images backup http://forums.fedoraforum.org/archive/index.php/t-28255.html This give a "dirty" solucion for remove special thing of ext3 (Selinux remove resize_inode and ext_attr features) witch cause the error in ghost. I hope somebody help with the problem of norton ghost and clone centos 4. :) ----------- sfabkk 2005-07-11,

Hi, I have two 3TB (hardware RAID-5) ext3 filesystems and recently added 1TB to each. I resized each filesystem and e2fsck -f reports that both are fine. However, when I look at the ext3 parameters with tune2fs -l one seems to have some parameters that the other one doesn't. In particular, one has: "Reserved GDT blocks", "Filesystem created", "Default directory

Hi, I'm about to roll out a whole bunch of Redhat Enterprise 4 workstations and have run into problems cloning from the original. Normally I would use ghost (v7.5) because it does a nice job when cloning to a different sized disk.Unfortunately it comes up with read error 29004. Looking around it seems that Symantec don't support Fedora Core 3 (with Ghost v.8 - don't know if v.9 works

Hi, I've installed a few Fedora Core 4 and Fedora Core 5 recently, and found that the new ext3 file systems created with new mkfs.ext3(1.38+) has one more field than EXT3 created with old mkfs.ext3(1.34-), even the latter's dir_index feature was turned on and file systems were upgraded with "e2fsck -y -f -D" command. I have three questions thereafter: 1) what does the

Does Fsync of a file on a ext3 fs mounted with "ordered" option(the default) result in flush the dirty data buffers in the fs that correspond to previous transactions. In other words, if I keep writing to file1 (lots of data), log something to file2, keep fsyncing file2 after every write - does this mean file1 data would be committed by fsyncs on file2. Please copy me on your replies

On 8/17/14, 12:28 PM, Roland Olbricht wrote: > Hello everybody, > > first of all thank you the development of Ext2/3/4. It works like a > charm and makes it possible to base applications on it. > However, "df" says: > > Filesystem 1K-blocks Used Available Use% Mounted on > ... > /dev/sdc 468346644 409888536 35015532 93% /opt/ssd >

Hello, I have 2 boxes with 1.5TB storage with ext3 fs, and the kernel is 2.6.11.8. I'm using E2fsprogs 1.37 for FS creation. And, Filesystem revision #: 1 (dynamic) There are 2 scenarios: 1. All SATA drives, RAID5 2. All PATA drives, RAID5 and wrapped in log volumes. I'm having lots of issues with fsck. I did search, but somehow not getting the right information. needs_recovery

Hello guys, I have some difficulties to understand what really are the numbers behing "df" and tune2fs. You'll find the output of tune2fs and df below, on which my maths are based. Here are my maths: A tune2fs on an ext3 FS tell me the FS size is 3284992 block large. It also tell me that the size of one block is 4096 (bytes if I'm not wrong?). So my maths tell me that the disk

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

Hello everybody, first of all thank you the development of Ext2/3/4. It works like a charm and makes it possible to base applications on it. However, now I have the first time where I need more information to understand the behaviour of a ext4 installation on a 480 GB harddisk. It holds a database with a size of 355 GB, as said by "du -m": ... 355263 /opt/ssd However,

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

Thanks for you help. I also tried adding some other informations as you suggest: I can also take into account: - "Reserved block count: XXXXXXX" from tune2fs that gives me the number of blocks reserved for root - Reserved GDT blocks: XXX But I didn't thought about the FS journal. How can I gather information about it? (it's size and any other information?) 2013/9/16

On 9/16/13 5:16 AM, Nicolas Michel wrote: > Hello guys, > > I have some difficulties to understand what really are the numbers > behing "df" and tune2fs. You'll find the output of tune2fs and df > below, on which my maths are based. > > Here are my maths: > > A tune2fs on an ext3 FS tell me the FS size is 3284992 block large. It > also tell me that

Hi, Using dumpe2fs I have been able to determine that all of my alternate ext3 superblocks are corrupted (not clean), and only the primary superblock is valid, i.e. mount works and the ordered journal is applied. When the primary superblock gets flakey, i.e. the ext_attr Filesystem feature goes missing - not sure why this occurs. At this point, the mount does not apply the journal using the

Hi, all, I'm a newbie to ext3 file system, but what a pity if ext3 could not shrink after containing files and subdirectories get deleted. If the ext3 directory could not shrink, then another natural question is: can the deleted directory entries be overwritten by new files/subdirs? The following is an example to detail my question: Suppose a directory named myDir hold 3 files a, b, c.

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

On 9/16/13 9:44 AM, Nicolas Michel wrote: > Thanks for you help. I also tried adding some other informations as you suggest: > I can also take into account: > - "Reserved block count: XXXXXXX" from tune2fs that gives me the > number of blocks reserved for root > - Reserved GDT blocks: XXX > > But I didn't thought about the FS journal. How can I gather

Hello Eric, thank you for the quick reply and the explanations. > dumpe2fs -h output might show us that. Filesystem volume name: <none> Last mounted on: /opt/ssd Filesystem UUID: 75d6aae6-1746-4260-994b-148dfdb5af95 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype

Yes indeed it is probably what's going on. what filesystem are you using and what are the mount options? ? Original Message ? From: lists at bago.org Sent: November 22, 2017 4:26 PM To: gluster-users at gluster.org Subject: [Gluster-users] error "Not able to add to index" in brick logs in my /var/log/gluster/bricks/mybrick-path.log I get thousands of those errors: ------