similar to: debugfs.ocfs2 and Feature Incompat

We have an application that has many processing threads writing more than a billion files ranging from 2KB ? 50KB, with 50% under 8KB (currently there are 700 million files). The files are never deleted or modified ? they are written once, and read infrequently. The files are hashed so that they are evenly distributed across ~1,000,000 subdirectories up to 3 levels deep, with up to 1000 files

Hi List, i'd like to share with you what happened yesterday. Kernel 2.6.36.1 ocfs2-tools 1.6.3 (latest). I had an old OCFS2 partition created with a 2.6.32 kernel and ocfs2 tools 1.4.5. I unmounted all partitions on all nodes in order to enable discontig-bg. I then used tunefs to add discontig-bg, inline-data and indexed-dirs. During indexed-dirs tunefs segfaulted and since then, fsck

Hello. I plan to use OCFS2 + DRBD for email server. Problem: I use "seeker" for testing http://www.linuxinsight.com/how_fast_is_your_disk.html And get this: Results: 65 seeks/second, 15.23 ms random access time Then I do rm of many files - it fals to 10 seeks/second and performance is terrible. What can I do to increase it? What`s wrong? Below is many info. What we have: Debian

Hi all. I have a 50 GB OCFS2 file system. I'm currently using ~26GB of space but df is reporting 43 GB used. Any ideas how to find out where the missing 17GB is at? The file system was formatted with a 16K cluster & 4K block size. Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, We are trying to use OCFS2 as VM storage. After running into problems with qemu's disk_mirror feature we now think there could be a problem with the FIEMAP ioctl in OCFS2. As far as I understand the situation looks like this: Qemu inquiries the FS if the given section of the image is already allocated via the FIEMAP ioctl [1] It especially checks if fm_mapped_extents is greater 0.

One of ocfs2 filesystem has some errors. 1. fsck.ocfs2 informs me that : "I/O error on channel while reading .. " It was NOT TRUE - I was able to read and write entire storage over the network multiple times. 2. becouse of CRC errors and suggestion to disable metaecc I run tunefs.ocfs2 --fs-features=nometaecc /dev/xxx funefs allocate 9,89 GB of virtual memory and 95% of

Hi List, i've upgraded some machines to linux kernel from 2.8.38 to 3.0.4. Now i'm always seeing this message when mounting an ocfs2 volume: [ 38.745584] (mount.ocfs2,3315,4):ocfs2_global_read_info:403 ERROR: status = 24 [ 38.776395] (mount.ocfs2,3315,4):ocfs2_global_read_info:403 ERROR: status = 24 ocfs2-tools 1.6.3-1 Stefan

Hello, I'm writing from the otherside of the world from where my systems are, so details are coming in slow. We have a 6TB OCFS2 volume across 20 or so nodes all running OEL5.4 running ocfs2-1.4.4. The system has worked fairly well for the last 6-8 months. Something has happened over the last few weeks which has driven write performance nearly to a halt. I'm not sure how to proceed, and

I need add extra 2 nodes into current 3 nodes ocfs2 file system which means 5 nodes share this file system after it. I think this file system creates by mkfs.ocfs2 -b .. -N 4 .. which only allows 4 nodes. Questions: 1. How to verify parameter when this file system created? In this case, it is 4 nodes. 2. I assume I have to recreate the files system which will lost contains, if I use

Hi all, I upgraded ocfs from 1.2 to 1.4 after the update I launched tunefs.ocfs2 to enable the new ocfs2 features (sparse files and unwritten extents). tunefs.ocfs2 is now running since 2 days (12T partition) and I need my system back to production, can I safety abort tunefs.ocfs2? thanks Nicola

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

Two patches follow this message. One fixes the default implementation of SEEK_HOLE/DATA. This patch applies atop Josef's last posted patch. The second patch implements the same on ocfs2. The test tool for the same is available here. http://oss.oracle.com/~smushran/seek_data/seek_test.c It is improved since the last post. It runs cleanly on zfs, ocfs2 and ext3 (default behavior). Users

I am working currently on cloning on a regular basis our production OCFS2 volumes to our test environment. For the database (Oracle 10G R2 RAC) we put it into backup mode, then execute a Snapclone on our 3Par SAN. Then we use RemoteCopy and SnapClone to our development 3Par SAN. To recover the OCFS2 volume I got through the following steps: Stop database umount /export/<volume name> Log

I am trying to make a mysql standby setup with 2 machines, one primary and one hot standby, which both share disk for the data directory. I used tunefs.ocfs2 to change the number of open slots to 1 since only one machine should be accessing it at a time. This way it is fairly safe to assume one shouldn't clobber the other's data. Only problem is, if one node dies, the mount lock still

All, This is hopefully the final drop of the patches for adding global heartbeat to the o2cb stack. The diff from the previous set is here: http://oss.oracle.com/~smushran/global-hb-diff-2010-10-07 Implemented most of the suggestions provided by Joel and Wengang. The most important one was to activate the feature only at the end, Also, got mostly a clean run with checkpatch.pl. Sunil

Hello, I have found, that ocfs2 is very slow when doing I/O operation without cache. See a simple test: ng-vvv1:~# dd if=/data/verejna/dd-1G bs=1k | dd of=/dev/null 1048576+0 records in 1048576+0 records out 1073741824 bytes (1.1 GB) copied, 395.183 s, 2.7 MB/s 2097152+0 records in 2097152+0 records out 1073741824 bytes (1.1 GB) copied, 395.184 s, 2.7 MB/s The underlying block device is quite

The patch was created against a 1.4 tree. However, it applies cleanly to mainline too. The patch has been lightly tested. I am running fill_verify_holes on a non sparse volume currently. Please review. Sunil

Currently f_fsid of struct kstatfs returned from ocfs2_statfs() is undefined (at least it should be filled with 0). Since in some conditions, f_fsid value might be used as (f_fsid, ino) pare to uniquely identify a file, ocfs2 should return a defined unique f_fsid value from ocfs2_statfs(). This patch uses uuid_hash as a unique ID to initiate f_fsid value, the 32bits width is enough for ocfs2

I am looking at possibility of using OCFS2 with an existing application that requires very high throughput for read and write file access. Files are created by single writer (process) and can be read by multiple reader, possibly while the file is being written. 100+ different files may be written simultaneously, and can be read by 1000+ readers. I am currently using XFS on a local filesystem,

One line fix from Joel's version. Also, some comments removed. 18:58 <sunil> wc->w_first_new_cpos = 18:58 <sunil> - ocfs2_align_bytes_to_clusters(inode->i_sb, i_size_read(inode)); 18:58 <sunil> + ocfs2_clusters_for_bytes(inode->i_sb, i_size_read(inode));