☰

df -h mostrando saída errada em GB

tag-icon • tag-icon ubuntu-10.04 coreutils df
df -h mostrando saída errada em GB

Se eu listar a saída do df para KB, MB e GB, eles não correspondem, 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, então está um pouco errado, mas OK
  • 12796048 KB = 12,2 GB, 12407 MB também equivale a 12,2 GB

então por que df está mostrando 13 GBOu eu estou esquecendo de alguma coisa?

Aqui está a listagem completa do 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 do Coreutils parece ser 7.4, como info coreutilsmostra

Este manual documenta a versão 7.4 dos utilitários principais do GNU,

Responder1

dfsempre arredonda a saída legível por humanos ( -he -H).

A partir de seu código-fonte no pacote coreutils, lib/human.huma enumeração de opções para a human_readablefunção que fornece 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 in human.c, que adiciona true(ou seja 1, ) se nenhuma outra opção de arredondamento mostrada acima estiver definida (não é, -hapenas 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 número 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;
}

Responder2

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

Wikipédia: isso leva à ineficiência de espaço devido à fragmentação interna, uma vez que os comprimentos dos arquivos geralmente não são múltiplos inteiros do tamanho do bloco e, portanto, o último bloco de arquivos permanecerá parcialmente vazio.Isso criará espaço livre, que equivale em média a meio bloco por arquivo.Alguns sistemas de arquivos mais recentes tentam resolver isso por meio de técnicas chamadas subalocação de blocos e fusão final.

Editar:

A página de manual diz o seguinte:

SIZE pode ser (ou pode ser um número inteiro opcionalmente seguido por) um dos seguintes: kB 1000, K 1024, MB 1000*1000, M 1024*1024 e assim por diante para 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.

Responder3

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

informação relacionada