Hide Forgot
potential problem during rebalancing of files after adding new nodes, not verified, logging the bug just to make sure. suppose DHT's subvol is expanded from 3 to 4, 1st subvolume is already 98% full, when we run rebalance script, will it copy files from other subvols to 1st subvol if 1st subvol has the linkfiles and cause disk to be 100% full?
When the additional server is added and the defrag scripts are run, it just syncs up the directory structure. But does not actually move the files.
(In reply to comment #1) > When the additional server is added and the defrag scripts are run, it just > syncs up the directory structure. But does not actually move the files. There are steps under defragmentation process: 1) rehashes the dht ext attrs. and create link files 2) copies the files - so that if there is link file on one subvol and actual file on another, the script copies from actual file location to the link file location (defragmentation)
> There are steps under defragmentation process: > 1) rehashes the dht ext attrs. and create link files > 2) copies the files - so that if there is link file on one subvol and actual > file on another, the script copies from actual file location to the link file > location (defragmentation) I tested on mainline and 3.0.4 but the link files are not created. Yes I did switch on the options `lookup-unhashed' and `unhased-stick-bit' in dht for this process.
(In reply to comment #3) > > There are steps under defragmentation process: > > 1) rehashes the dht ext attrs. and create link files > > 2) copies the files - so that if there is link file on one subvol and actual > > file on another, the script copies from actual file location to the link file > > location (defragmentation) > > I tested on mainline and 3.0.4 but the link files are not created. Yes I did > switch on the options `lookup-unhashed' and `unhased-stick-bit' in dht for this > process. no, catch me online sometime, i will explain. 1000s of link files can exist - because of renames or because of disks getting filledup.
with the new defrag scripts and 'gluster defrag' command this problem will be gone, because the files will be moved to corresponding node and then take the creation of link file for next file. Hence we will not get into the problem of '10000s of linkfiles' anymore. Fixed in master branch (3.1.x)