Obtendo espaço livre do sistema de arquivos

1

Este não é um problema como tal, mais um pedido de informação baseado na ignorância do sistema de arquivos Linux. A pergunta muito curta é:

Como descubro quanto espaço livre e usado há no volume a partir do qual o Ubuntu está sendo executado?

Mais detalhes:

Estou executando o Ubuntu 12.04 a partir de um stick USB3 de 64 Gb, criado a partir da inicialização de um DVD do Ubuntu 12.04 de um ano e da execução do Startup Disk Creator. A razão para isso é que o Master Boot Record no meu disco rígido, segurando o Windoze 7, ficou de saco cheio e, enquanto aguardo um disco de recuperação, estou executando o Ubunto off USB ou DVD como um 'teste'. (E continuará rodando o Ubuntu depois de restaurar o Windoze, já que eu redescobri meu amor pelo pinguim: o))

Depois de instalar o Ubuntu no pendrive, executei o aplicativo de atualização de software, que baixou cerca de 450Mb de atualizações e levou algumas horas para ser instalado no dispositivo. Algumas vezes recebi uma mensagem dizendo que o espaço em disco era curto. Então eu olhei no gerenciador de arquivos (ou o que quer que seja chamado hoje em dia) e não pude ver o bastão listado, apenas:

  • SISTEMA
  • disco rígido (listado como 479Gb Filesystem)
  • duas outras partições criadas pela Windoze
  • "4.3GB Filesystem" que quando eu tento abrir dá o erro "Não foi possível encontrar / cow", e quando tento desmontar ele me diz que não posso porque não está montado - D'OH !!

Editar: captura de tela do gerenciador de arquivos

Editar: captura de tela de aviso de pouco espaço em disco

O que não consigo ver é o pen drive USB do qual estou executando o Ubuntu. Para onde foi, alguém sabe?

Isso está tangencialmente relacionado a uma pergunta anterior sobre ferramentas do sistema , na qual eu Estou tentando obter controle e conhecimento do sistema na mais recente encarnação do Ubuntu.

    
por Fred Riley 31.10.2013 / 22:01

1 resposta

0

Existem algumas ferramentas que utilizo nesta situação: df , du e mount

du é o mais útil para caçar o culpado que preencheu seu sistema de arquivos:

$du -h --max-depth=1

No entanto, na raiz do sistema de arquivos, / , você não terá permissão para acessar todos os diretórios para obter uma leitura do tamanho dos arquivos, portanto será necessário que sudo obtenha privilégios totais. Acabei de fazer isso no nosso servidor em / e nosso ataque é meio grande, então eu desisti disso.

Exemplos seguem:

15:08 chris@server /$ sudo du -h --max-depth=1
8.0K    ./mnt
16K     ./build
4.1G    ./opt
4.0K    ./backup
12K     ./media
13M     ./lib32
38M     ./root
300K    ./dev
6.0M    ./sbin
2.4G    ./lib
2.9G    ./var
4.0K    ./selinux
50M     ./home
2.3G    ./usr
0       ./proc
7.9M    ./bin
5.9M    ./tmp
200K    ./srv
4.0K    ./run
0       ./sys
4.0K    ./cdrom

Eu apertei ctrl + c porque eu terminei de esperar no /raid ... Então vamos ver o que o df diz:

15:14 chris@server /$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb7              92G  9.0G   79G  11% /
none                  1.9G  300K  1.9G   1% /dev
none                  1.9G     0  1.9G   0% /dev/shm
none                  1.9G  7.3M  1.9G   1% /var/run
none                  1.9G     0  1.9G   0% /var/lock
none                  1.9G     0  1.9G   0% /lib/init/rw
/dev/sda1             3.6T  2.3T  1.2T  66% /raid
/dev/sdb9             276M   88M  175M  34% /boot
/dev/sdb8              88G  3.1G   81G   4% /var

Oh, uau, o ataque está cheio de dois terços, talvez valha a pena esperar para descobrir?

15:15 chris@server /raid$ !du
du -h --max-depth=1
852M    ./www
20K     ./investedin
9.8M    ./ups
99M     ./dealers
3.0G    ./photoshoot
69M     ./catalog_tech
86G     ./misc
4.9G    ./marketing
16G     ./pics
193G    ./Video
37G     ./mechanical_design
14M     ./tmp
16K     ./lost+found
93G     ./programs
16K     ./.Trash-1000
17G     ./Products
1.3G    ./vendors
1.1G    ./docs
128K    ./.Trash-1001
20M     ./customers
2.9M    ./po_invoices
18M     ./_SCANS

Bem, ainda está acontecendo, então eu vou ser paciente e deixá-lo ir em segundo plano. Para analisar o acima, eu analiso os tamanhos dos diretórios para quem é o porco do disco. Observe que ./programs é 93G. Se isso é inesperado, você começa a perfurar essa árvore.

Eu prefiro du -h --max-depth=1 porque com mais profundidade, você obtém uma tonelada de saída e, neste caso, você pode precisar apenas de um diretório onde um log ficou louco (como em um website?)

Editado para adicionar:
E mount nem sempre é aplicável para o seu caso exato, no entanto, eu usei o Linux e as técnicas acima para resgatar uma instalação do Windows sem espaço livre. mount pode ajudá-lo a ver quais discos rígidos são montados onde. Observe também como df também sugere a saída de mount .

15:25 chris@server ~$ mount
/dev/sdb7 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda1 on /raid type ext4 (rw)
/dev/sdb9 on /boot type ext4 (rw)
/dev/sdb8 on /var type ext4 (rw)

O que o acima nos diz é que a primeira partição do primeiro disco rígido (um RAID 5 de hardware) está em / raid e o "disco rígido" real no computador é sdb. Com / em sdb7, isso me lembra que este é o segundo ou terceiro SO que eu tenho neste disco neste servidor. Eu coloquei /var em uma partição separada para quando os logs enlouquecerem.

    
por Chris K 31.10.2013 / 23:35