similar to: Large file - match process taking days

Hi list, I have a few large image files (VMware workstation VMDKs and TrueCrypt containers) which I routinely back up over the network to a btrfs raid10 volume via bigsync (https://code.google.com/p/bigsync/). The VM images in particular get really fragmented due to CoW, which is expected. I haven''t yet switched off CoW on the backups directory mainly to experiment and see what

pylon:/var/lib/glusterd/vols/dev_apkmirror_data # ack shared-brick-count dev_apkmirror_data.pylon.mnt-pylon_block3-dev_apkmirror_data.vol 3: option shared-brick-count 3 dev_apkmirror_data.pylon.mnt-pylon_block2-dev_apkmirror_data.vol 3: option shared-brick-count 3 dev_apkmirror_data.pylon.mnt-pylon_block1-dev_apkmirror_data.vol 3: option shared-brick-count 3 Sincerely, Artem --

Hi Nithya, I'm on Gluster 4.0.1. I don't think the bricks were smaller before - if they were, maybe 20GB because Linode's minimum is 20GB, then I extended them to 25GB, resized with resize2fs as instructed, and rebooted many times over since. Yet, gluster refuses to see the full disk size. Here's the status detail output: gluster volume status dev_apkmirror_data detail Status

A) Resilver = Defrag. True/false? B) If I buy larger drives and resilver, does defrag happen? C) Does zfs send zfs receive mean it will defrag? -- This message posted from opensolaris.org

Hello everybody, reading about the speed improvements possible with (on boot) preloaded files (which should be continuous on disk) I searched for a ext3 defrag program. I found an ext2 defrag program (http://www.ibiblio.org/pub/Linux/system/filesystems/defrag-0.70.tar.gz, available in debian as defrag) which would have an optimal feature (moving files by a list) but refuses to work on ext3.

hello, i've set up a domain controller to replace a production server. both servers use profile redirection for all user environment directories. my problem is that when logging onto the new domain and server, windows will create in the %userprofile% local directory an Application Directory containing Microsoft/Credentials/*SID*, although a copy exists on the server. this directory is used

When designing a filesystem, is fragmentation really an issue if access to the disk can be done using scatter-gather DMA techics ?

Dear R users, subject: How to filter XY pairs of inacurate gps position along track, taking into account the time index to not mix track from different days in one average track or subject as: How to filter XY pairs of inacurate gps position: (latitude, longtitude) to get estimated correct position before calculating track i.e. How to estimate (time series? )? How to filter XY pairs of

Ok, it looks like the same problem. @Amar, this fix is supposed to be in 4.0.1. Is it possible to regenerate the volfiles to fix this? Regards, Nithya On 17 April 2018 at 09:57, Artem Russakovskii <archon810 at gmail.com> wrote: > pylon:/var/lib/glusterd/vols/dev_apkmirror_data # ack shared-brick-count > dev_apkmirror_data.pylon.mnt-pylon_block3-dev_apkmirror_data.vol > 3:

Hi, I use btrfs on most of my volumes on my laptop, and I''ve always felt booting was very slow, but definitely sure is slow, is starting up Google Chrome: encrypted ext4: ~20s btrfs: ~2:11s I have tried different things to find out exactly what is the issue, but haven''t quite found it yet. Here''s some stuff I got from latencytop, not sure if would be helpful:

Someone recently posted the following statement midway down the page at http://forums.gentoo.org/viewtopic-t-305871-postdays-0-postorder-asc-highlight-ext3+ordered+data-start-25.html >You don't need to defragment ext2/ext3 because as you use the >filesystem file blocks and inodes are moved around and reallocated >to keep the data nearly contiguous. It's not perfect, but it

Hi Artem, Was the volume size correct before the bricks were expanded? This sounds like [1] but that should have been fixed in 4.0.0. Can you let us know the values of shared-brick-count in the files in /var/lib/glusterd/vols/dev_apkmirror_data/ ? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1541880 On 17 April 2018 at 05:17, Artem Russakovskii <archon810 at gmail.com> wrote: > Hi

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 zpool and zfs report different free space because zfs takes into account an internal reservation of 32MB or 1/64 of the capacity of the pool, what is bigger. So in a 2TB Harddisk, the reservation would be 32 gigabytes. Seems a bit excessive to me... - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es -

What version of Gluster are you running? Were the bricks smaller earlier? Regards, Nithya On 15 April 2018 at 00:09, Artem Russakovskii <archon810 at gmail.com> wrote: > Hi, > > I have a 3-brick replicate volume, but for some reason I can't get it to > expand to the size of the bricks. The bricks are 25GB, but even after > multiple gluster restarts and remounts, the

To clarify, I was on 3.13.2 previously, recently updated to 4.0.1, and the bug seems to persist in 4.0.1. Sincerely, Artem -- Founder, Android Police <http://www.androidpolice.com>, APK Mirror <http://www.apkmirror.com/>, Illogical Robot LLC beerpla.net | +ArtemRussakovskii <https://plus.google.com/+ArtemRussakovskii> | @ArtemR <http://twitter.com/ArtemR> On Mon, Apr

That might be the reason. Perhaps the volfiles were not regenerated after upgrading to the version with the fix. There is a workaround detailed in [2] for the time being (you will need to copy the shell script into the correct directory for your Gluster release). [2] https://bugzilla.redhat.com/show_bug.cgi?id=1517260#c19 On 17 April 2018 at 09:58, Artem Russakovskii <archon810 at

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

I just remembered that I didn't run https://docs.gluster.org/en/v3/Upgrade-Guide/op_version/ for this test volume/box like I did for the main production gluster, and one of these ops - either heal or the op-version, resolved the issue. I'm now seeing: pylon:/var/lib/glusterd/vols/dev_apkmirror_data # ack shared-brick-count dev_apkmirror_data.pylon.mnt-pylon_block3-dev_apkmirror_data.vol

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

Hi, I have a 3-brick replicate volume, but for some reason I can't get it to expand to the size of the bricks. The bricks are 25GB, but even after multiple gluster restarts and remounts, the volume is only about 8GB. I believed I could always extend the bricks (we're using Linode block storage, which allows extending block devices after they're created), and gluster would see the