diff --git a/cmdline/state.c b/cmdline/state.c index 9a9151a2..1ac67385 100644 --- a/cmdline/state.c +++ b/cmdline/state.c @@ -826,8 +826,8 @@ void state_config(struct snapraid_state* state, const char* path, const char* co /* LCOV_EXCL_STOP */ } - /* convert to GiB */ - state->autosave *= 1024 * 1024 * 1024; + /* convert to GB */ + state->autosave *= GIGA; } else if (tag[0] == 0) { /* allow empty lines */ } else if (tag[0] == '#') { diff --git a/snapraid.1 b/snapraid.1 index 48e8e564..c413c2a0 100644 --- a/snapraid.1 +++ b/snapraid.1 @@ -1173,29 +1173,29 @@ of RAM memory to run in the 32 bits version, and TS*36/BS in the 64 bits one. Where TS is the total size in bytes of your disk array, and BS is the block size in bytes. .PP -For example with 4 disk of 3 TiB and a block size of 256 KiB +For example with 8 disk of 4 TB and a block size of 256 KiB (1 KiB = 1024 bytes) you have: .PP -RAM = (4 * 3 * 2^40) * 28 / (256 * 2^10) = 1.4 GiB +RAM = (8 * 4 * 10^12) * 28 / (256 * 2^10) = 3.2 GiB .PD 0 .PP .PD .PP -Another reason to use a different blocksize is if you have a lot of small -files. In the order of many millions. +Another reason to use a different blocksize is if you have a lot of +small files. In the order of many millions. .PP For each file, even of few bytes, a whole block of parity is allocated, and with many files this may result in a lot of unused parity space. And when you completely fill the parity disk, you are not allowed to add more files in the data disks. -Anywa, the wasted parity doesn\'t sum between data disk. Wasted space +Anyway, the wasted parity doesn\'t sum between data disks. Wasted space resulting from a high number of files in a data disk, limits only the amount of data in such data disk and not in others. .PP As approximation, you can assume that half of the block size is wasted for each file. For example, with 100000 files and a 256 KiB -block size, you are going to waste 12 GiB of parity, that may result -in 12 GiB less space available in the data disk. +block size, you are going to waste 13 GB of parity, that may result +in 13 GB less space available in the data disk. .PP You can get the amount of wasted space in each disk using \[dq]status\[dq]. This is the amount of space that you must leave free in the data @@ -1204,7 +1204,7 @@ If this value is negative, it means that your are near to fill the parity, and it represents the space you can still waste. .PP To avoid the problem, you can use a bigger partition for parity. -For example, if you have the parity partition bigger than 12 GiB +For example, if you have the parity partition bigger than 13 GB than data disks, you have enough extra space to handle up to 100000 files in each data disk. .PP @@ -1218,17 +1218,15 @@ mkfs.ext4 \-m 0 \-T largefile4 DEVICE .PD .RE .PP -This results in about 1.5% of extra space. Meaning about 48 GiB for -a 3 TiB disk, that allows about 400000 files in each data disk without +This results in about 1.5% of extra space. Meaning about 60 GB for +a 4 TB disk, that allows about 460000 files in each data disk without any wasted space. -.SS autosave SIZE_IN_GIBIBYTES +.SS autosave SIZE_IN_GIGABYTES Automatically save the state when syncing after the specified amount -of GiB processed. +of GB processed. This option is useful to avoid to restart from scratch long \[dq]sync\[dq] commands interrupted by a machine crash, or any other event that may interrupt SnapRAID. -The SIZE argument is specified in gibibytes. Where one gibi bytes -is 1073741824 bytes. .SS pool DIR Defines the pooling directory where the virtual view of the disk array is created using the \[dq]pool\[dq] command. diff --git a/snapraid.conf.example b/snapraid.conf.example index eeed60a3..0e63a865 100644 --- a/snapraid.conf.example +++ b/snapraid.conf.example @@ -54,13 +54,12 @@ exclude /lost+found/ #blocksize 256 # Automatically save the state when synching after the specied amount -# of GiB processed (uncomment to enable). +# of GB processed (uncomment to enable). # This option is useful to avoid to restart from scratch long 'sync' # commands interrupted by a machine crash. # It also improves the recovering if a disk break during a 'sync'. -# The SIZE argument is specified in gibi bytes -> 1073741824 bytes # Default value is 0, meaning disabled. -# Format: "autosave SIZE_IN_GiB" +# Format: "autosave SIZE_IN_GB" #autosave 500 # Defines the pooling directory where the virtual view of the disk diff --git a/snapraid.conf.example.windows b/snapraid.conf.example.windows index 47739317..f77da725 100644 --- a/snapraid.conf.example.windows +++ b/snapraid.conf.example.windows @@ -58,13 +58,12 @@ exclude \Windows\ #blocksize 256 # Automatically save the state when synching after the specied amount -# of GiB processed (uncomment to enable). +# of GB processed (uncomment to enable). # This option is useful to avoid to restart from scratch long 'sync' # commands interrupted by a machine crash. # It also improves the recovering if a disk break during a 'sync'. -# The SIZE argument is specified in gibi bytes -> 1073741824 bytes # Default value is 0, meaning disabled. -# Format: "autosave SIZE_IN_GiB" +# Format: "autosave SIZE_IN_GB" #autosave 500 # Defines the pooling directory where the virtual view of the disk diff --git a/snapraid.d b/snapraid.d index 2dbbffde..9389632a 100644 --- a/snapraid.d +++ b/snapraid.d @@ -917,26 +917,26 @@ Configuration in the 64 bits one. Where TS is the total size in bytes of your disk array, and BS is the block size in bytes. - For example with 4 disk of 3 TiB and a block size of 256 KiB + For example with 8 disk of 4 TB and a block size of 256 KiB (1 KiB = 1024 bytes) you have: - :RAM = (4 * 3 * 2^40) * 28 / (256 * 2^10) = 1.4 GiB + :RAM = (8 * 4 * 10^12) * 28 / (256 * 2^10) = 3.2 GiB - Another reason to use a different blocksize is if you have a lot of small - files. In the order of many millions. + Another reason to use a different blocksize is if you have a lot of + small files. In the order of many millions. For each file, even of few bytes, a whole block of parity is allocated, and with many files this may result in a lot of unused parity space. And when you completely fill the parity disk, you are not allowed to add more files in the data disks. - Anywa, the wasted parity doesn't sum between data disk. Wasted space + Anyway, the wasted parity doesn't sum between data disks. Wasted space resulting from a high number of files in a data disk, limits only the amount of data in such data disk and not in others. As approximation, you can assume that half of the block size is wasted for each file. For example, with 100000 files and a 256 KiB - block size, you are going to waste 12 GiB of parity, that may result - in 12 GiB less space available in the data disk. + block size, you are going to waste 13 GB of parity, that may result + in 13 GB less space available in the data disk. You can get the amount of wasted space in each disk using "status". This is the amount of space that you must leave free in the data @@ -945,7 +945,7 @@ Configuration the parity, and it represents the space you can still waste. To avoid the problem, you can use a bigger partition for parity. - For example, if you have the parity partition bigger than 12 GiB + For example, if you have the parity partition bigger than 13 GB than data disks, you have enough extra space to handle up to 100000 files in each data disk. @@ -954,18 +954,16 @@ Configuration :mkfs.ext4 -m 0 -T largefile4 DEVICE - This results in about 1.5% of extra space. Meaning about 48 GiB for - a 3 TiB disk, that allows about 400000 files in each data disk without + This results in about 1.5% of extra space. Meaning about 60 GB for + a 4 TB disk, that allows about 460000 files in each data disk without any wasted space. - autosave SIZE_IN_GIBIBYTES + autosave SIZE_IN_GIGABYTES Automatically save the state when syncing after the specified amount - of GiB processed. + of GB processed. This option is useful to avoid to restart from scratch long "sync" commands interrupted by a machine crash, or any other event that may interrupt SnapRAID. - The SIZE argument is specified in gibibytes. Where one gibi bytes - is 1073741824 bytes. pool DIR Defines the pooling directory where the virtual view of the disk diff --git a/snapraid.txt b/snapraid.txt index 403225a7..f9821ccb 100644 --- a/snapraid.txt +++ b/snapraid.txt @@ -993,26 +993,26 @@ of RAM memory to run in the 32 bits version, and TS*36/BS in the 64 bits one. Where TS is the total size in bytes of your disk array, and BS is the block size in bytes. -For example with 4 disk of 3 TiB and a block size of 256 KiB +For example with 8 disk of 4 TB and a block size of 256 KiB (1 KiB = 1024 bytes) you have: -RAM = (4 * 3 * 2^40) * 28 / (256 * 2^10) = 1.4 GiB +RAM = (8 * 4 * 10^12) * 28 / (256 * 2^10) = 3.2 GiB -Another reason to use a different blocksize is if you have a lot of small -files. In the order of many millions. +Another reason to use a different blocksize is if you have a lot of +small files. In the order of many millions. For each file, even of few bytes, a whole block of parity is allocated, and with many files this may result in a lot of unused parity space. And when you completely fill the parity disk, you are not allowed to add more files in the data disks. -Anywa, the wasted parity doesn't sum between data disk. Wasted space +Anyway, the wasted parity doesn't sum between data disks. Wasted space resulting from a high number of files in a data disk, limits only the amount of data in such data disk and not in others. As approximation, you can assume that half of the block size is wasted for each file. For example, with 100000 files and a 256 KiB -block size, you are going to waste 12 GiB of parity, that may result -in 12 GiB less space available in the data disk. +block size, you are going to waste 13 GB of parity, that may result +in 13 GB less space available in the data disk. You can get the amount of wasted space in each disk using "status". This is the amount of space that you must leave free in the data @@ -1021,7 +1021,7 @@ If this value is negative, it means that your are near to fill the parity, and it represents the space you can still waste. To avoid the problem, you can use a bigger partition for parity. -For example, if you have the parity partition bigger than 12 GiB +For example, if you have the parity partition bigger than 13 GB than data disks, you have enough extra space to handle up to 100000 files in each data disk. @@ -1030,20 +1030,18 @@ with the command: mkfs.ext4 -m 0 -T largefile4 DEVICE -This results in about 1.5% of extra space. Meaning about 48 GiB for -a 3 TiB disk, that allows about 400000 files in each data disk without +This results in about 1.5% of extra space. Meaning about 60 GB for +a 4 TB disk, that allows about 460000 files in each data disk without any wasted space. -7.9 autosave SIZE_IN_GIBIBYTES +7.9 autosave SIZE_IN_GIGABYTES ------------------------------ Automatically save the state when syncing after the specified amount -of GiB processed. +of GB processed. This option is useful to avoid to restart from scratch long "sync" commands interrupted by a machine crash, or any other event that may interrupt SnapRAID. -The SIZE argument is specified in gibibytes. Where one gibi bytes -is 1073741824 bytes. 7.10 pool DIR -------------