df -h mostrando saída errada em GB

0

Se eu listar o resultado do df para KB, MB e GB, eles não corresponderão a, por exemplo,

$ df -k |grep xvdb
/dev/xvdb1            12796048    732812  11413172   7% /xxx
$ df -m |grep xvdb
/dev/xvdb1               12497       716     11146   7% /xxx
$ df -h |grep xvdb
/dev/xvdb1             13G  716M   11G   7% /xxx
  • 12796048 KB = 12496,14 MB, o que é pouco, mas está OK
  • 12796048 KB = 12,2 GB, 12407 MB também é 12,2 GB

então por que df está mostrando 13 GB ou estou faltando alguma coisa?

Aqui está a lista completa de df

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.5G  1.7G  5.5G  24% /
none                  5.8G  128K  5.8G   1% /dev
none                  5.8G     0  5.8G   0% /dev/shm
none                  5.8G   44K  5.8G   1% /var/run
none                  5.8G     0  5.8G   0% /var/lock
none                  5.8G     0  5.8G   0% /lib/init/rw
/dev/xvdb1             13G  716M   11G   6% /xxx

A versão Coreutils parece 7,4, como info coreutils mostra

This manual documents version 7.4 of the GNU core utilities,

    
por Anurag Uniyal 02.11.2012 / 17:04

3 respostas

2

df sempre preenche a saída legível por humanos ( -h e -H ).

De seu código-fonte no pacote coreutils, lib/human.h , um enum de opções para a função human_readable fornecendo arredondamento, conversão de unidades, etc.:

/* Options for human_readable.  */
enum
{
  /* Unless otherwise specified these options may be ORed together.  */

  /* The following three options are mutually exclusive.  */
  /* Round to plus infinity (default).  */
  human_ceiling = 0,
  /* Round to nearest, ties to even.  */
  human_round_to_nearest = 1,
  /* Round to minus infinity.  */
  human_floor = 2,
...

Observe o comentário: Round to plus infinity (default).

O arredondamento real provavelmente acontece na seguinte função em human.c , que adiciona true (ou seja, 1 ) se nenhuma outra opção de arredondamento mostrada acima estiver configurada (não é, -h somente define human_autoscale | human_SI | human_base_1024 , resultando em escalonamento automático usando 1024 como incremento de unidade e imprimindo o sufixo de estilo SI, ou seja, G ) e o valor não é um inteiro:

static long double
adjust_value (int inexact_style, long double value)
{
  /* Do not use the floorl or ceill functions, as that would mean
     checking for their presence and possibly linking with the
     standard math library, which is a porting pain.  So leave the
     value alone if it is too large to easily round.  */
  if (inexact_style != human_round_to_nearest && value < UINTMAX_MAX)
    {
      uintmax_t u = value;
      value = u + (inexact_style == human_ceiling && u != value);
    }

  return value;
}
    
por 02.11.2012 / 18:35
0

Normalmente, isso está associado a ineficiências de um sistema de formatação. Por exemplo, um arquivo pode ser apenas 12,2g (o que você está correto), mas no disco físico pode ocupar 13GB de espaço. Isso se deve ao " bloqueio " e é um resultado da fragmentação.

Wikipedia: This leads to space inefficiency due to internal fragmentation, since file lengths are often not integer multiples of block size, and thus the last block of files will remain partially empty. This will create slack space, which averages half a block per file. Some newer file systems attempt to solve this through techniques called block suballocation and tail merging.

Editar :

A página man diz isso:

SIZE may be (or may be an integer optionally followed by) one of fol- lowing: kB 1000, K 1024, MB 1000*1000, M 1024*1024, and so on for G, T, P, E, Z, Y.

Isso me leva a acreditar que pode estar usando MB em vez de M, então isso mostraria 12.796 - arredondando para 13 talvez.

    
por 02.11.2012 / 17:08
0

Minha experiência recente com sistemas de arquivos multi-terabytes é que o escalonamento em 'df -h' pode ser confuso, porque a coluna 'tamanho total' é arredondada para um número inteiro e sempre para cima, enquanto o 'usado' e 'usado' as colunas disponíveis são dimensionadas e arredondadas para uma casa decimal. Isso pode fazer com que o tamanho total mostre quase uma 'unidade' inteira maior do que é. O efeito é mais óbvio quando o tamanho é tal que você está em pequenos números - seja MB, GB ou TB.

    
por 04.04.2013 / 16:53