search for: clusterse

On Fri, Apr 21, 2023 at 03:35:01PM +0800, Joseph Qi wrote: > Hi, > Could you please share a reproducer? > Anyone could access & download the URL [1] (I wrote it in patch commit log) without register SUSE account. Please check attachment file, which I downloaded from [1] and modified under the BZ comment 1. The trigger method is also in comment 1, I copy here: ./defragfs_test.sh -d

Another simple question. How do I calculate the size of the volume from the superblock? Do I just use the two fields: u_int32_t s_blocksize_bits; /* Blocksize for this fs */ u_int32_t s_clustersize_bits; /* Clustersize for this fs */ What is the formula to use? Thanks, John

Just a quick question. What is the maximum and minimum volume sizes that OCFS2 supports? I'm working on doing a plugin for EVMS to support OCFS2. One of the functions needs that info. Thanks, John

Hi all, I created a OCFS2 volume with a block size of 4kB and a clustersize of 4kB. After I mounted the volume the first time there have been already over 600 MB in use. Then I started to copy a directory with a overall size of 1784 MB(measured on an XFS with "du"). After an hour about 4 GB(!) have been used on the OCFS2 volume so I stopped the copy. The files I copied are mostly

This fixes three issues on move extents ioctl without auto defrag: a) In ocfs2_find_victim_alloc_group(), we have to convert bits to block first in case of global bitmap. b) In ocfs2_probe_alloc_group(), when finding enough bits in block group bitmap, we have to back off move_len to start pos as well, otherwise it may corrupt filesystem. c) In ocfs2_ioctl_move_extents(), set me_threshold both for

This commit fixes three issues on non-auto defrag path (defragfs.ocfs2 doesn't set OCFS2_MOVE_EXT_FL_AUTO_DEFRAG on range.me_flags): - For ocfs2_find_victim_alloc_group(), old code forgot enlarge bitmap range for global_bitmap case. Old code could generate negative vict_bit. - For ocfs2_probe_alloc_group(), old code forgot back off move_len when finding enough bitmap space. Old code has

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1), so stop forcing compat=0.10 for these targets. Thanks: Yaniv Kaul, Michal Skrivanek. --- v2v/output_rhev.ml | 4 ----

Hello Rprofessionals, The SOM-Obj works very well, when i normalize my data and the plot-function, too ! But i miss or didn't find the possibility , extract the information from the SOMplot "clusterSize" and "mean" for every cluster as quantitative information ( i.e. the DataFrame with an additional column which define the calculate clusters from SOM)? My intention -

Afternoon, We have an ocfs2 release 1.4 filesystem shared between two nodes (RHEL5). The filesystem in question is used exclusively for Oracle RMAN backups. A df -h shows the following: [root at imsthdb07 ~]# df -h /data/orabackup Filesystem Size Used Avail Use% Mounted on /dev/mapper/eva_mpio_myserver07_08_oracle_bkup0 250G

Hi all We are using a 2 node cluster with drbd 8 (primary/primary state) and ocfs2. Reading a file on one node while it will be written on the other node is very slow. Reading a file on node while it will be written on the same node is fast. In the first case the node which wants to read the file has to ask the other to downgrade the locklevel. In my opinion this is a bottleneck, if the files are

A lot of code runs 'qemu-img create' or 'truncate' to create blank disk images. In the past I resisted adding an API to do this, since it essentially duplicates what you can already do using other tools (ie. qemu-img). However this does simplify calling code quite a lot since qemu-img is somewhat error-prone to use (eg: don't try to create a disk called "foo:bar")

Hello, I think I found a bug when creating graphics on a PDF device using transparency. I'm using ggplots2 like this: comp <- ggplot(data, aes(x=Problemsize, y=Fitness)) + geom_smooth(fill=alpha("blue", 0.2), aes(colour=factor(Clustersize)), size=2) Which gives me a curve for each "Clustersize" with a transparent blue "cloud" around it, indication

In the guestfs_disk_create API we have traditionally allowed you to set backingfile without setting backingformat. The meaning of this is to let qemu autodetect the backing format when opening the overlay disk. However libvirt >= 6.0 refuses to even pass such disks to qemu (see https://bugzilla.redhat.com/show_bug.cgi?id=1798148). For this reason, move the autodetection earlier and make it

Use the common open_guestfs to open Guestfs handles, so we get debugging, tracing, and other common options set. --- v2v/convert_windows.ml | 4 +--- v2v/input_disk.ml | 2 +- v2v/input_libvirt_other.ml | 2 +- v2v/input_ova.ml | 2 +- v2v/output_glance.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_rhev.ml | 2 +- v2v/output_vdsm.ml | 2 +-

On 2/20/23 1:05 PM, Heming Zhao wrote: > This fixes three issues on move extents ioctl without auto defrag: > > a) In ocfs2_find_victim_alloc_group(), we have to convert bits to block > first in case of global bitmap. > b) In ocfs2_probe_alloc_group(), when finding enough bits in block group > bitmap, we have to back off move_len to start pos as well, otherwise it > may

Extend open_guestfs to take an optional ?identifier parameter. Use this parameter in virt-v2v which is currently the only place where we use the handle identifier. --- mllib/common_utils.ml | 3 ++- mllib/common_utils.mli | 2 +- v2v/output_rhev.ml | 3 +-- v2v/output_vdsm.ml | 3 +-- v2v/v2v.ml | 3 +-- v2v/windows.ml | 3 +-- 6 files changed, 7 insertions(+), 10

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. Since RHV 4.1, compat=1.1 is supported. Support for compat=1.1 is uncertain in RHV 4.0 even on RHEL 7 nodes. There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1). Therefore this

The quilt patch titled Subject: ocfs2: fix non-auto defrag path not working issue has been removed from the -mm tree. Its filename was ocfs2-fix-non-auto-defrag-path-not-working-issue.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From:

Support for RHEV with RHEL 6 nodes required us to output the old style qcow2 compat=0.10 images. Since RHEV 3.6 GA, RHEL 6 has not been supported as a RHEV node type. Since RHV 4.1, compat=1.1 is supported. (Support for compat=1.1 is uncertain in RHV 4.0 even on RHEL 7 nodes.) There are significant downsides to using qcow2 compat=0.10 instead of the modern default (compat=1.1). Therefore this

This is a note to let you know that I've just added the patch titled ocfs2: fix non-auto defrag path not working issue to the 6.2-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: ocfs2-fix-non-auto-defrag-path-not-working-issue.patch and it can be found in the queue-6.2 subdirectory.