Linux за българи: Форуми

ОС Suse Enterprise 10.0
Filesystem ReiserFS
SCSI дискове в HW RAID1
Руут дяла 27ГБ
Една сутрин установявам 99% заето дисково пространство  :o
Logwatch репорта от предната вечер показва 19GB free ?!
2 дни изследвам директория по директория - не мога да открия къде изчезнаха тези гиги?
Ето данните в момента:

/ # df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              28G   27G  1.3G  96% /
tmpfs                1013M     0 1013M   0% /dev/shm
/dev/sda3              70G   47G   24G  67% /DATA
/dev/sdb1             151G  1.6G  149G   2% /backup

du -shx /
8.0G    /

Някакви идеи какво може да става и какво може да погледна?

ОС Suse Enterprise 10.0
Filesystem ReiserFS
SCSI дискове в HW RAID1
Руут дяла 27ГБ
Една сутрин установявам 99% заето дисково пространство  :o
Logwatch репорта от предната вечер показва 19GB free ?!
2 дни изследвам директория по директория - не мога да открия къде изчезнаха тези гиги?
Ето данните в момента:

Цитат

/ # df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              28G   27G  1.3G  96% /
tmpfs                1013M     0 1013M   0% /dev/shm
/dev/sda3              70G   47G   24G  67% /DATA
/dev/sdb1             151G  1.6G  149G   2% /backup

Цитат

du -shx /
8.0G    /

Някакви идеи какво може да става и какво може да погледна?

du -sk /*
и обичайните заподозрени са:
/tmp
/var

lsof -a +L1 /
виж дали това ще изкара нещо...

du -sk /*
и обичайните заподозрени са:
/tmp
/var

Привет Капитане :)
/tmp е изпразнен, няма промяна.

du -sxh /var/
3.7G    /var/

du -skx дава същото, но само локланите файлове, без монтираните от други дялове (иначе се изкривява резултата)
Смущаващото е, че du -skx дава само 8Гб, докато df дава 27Gb  ::)
lsof не показа някакви увиснали процеси, които да пълнят дяла.

Сега се зачетох в една статия http://mradomski.wordpress.com/2007/01/08/finding-an-unlinked-open-file-and-other-lsof-uses/ ($2)
Същия случай, както ме посъветва solarflux:

lsof -a +L1 /
COMMAND   PID  USER   FD   TYPE DEVICE SIZE NLINK  NODE NAME
mysqld  13712 mysql    6u   REG    8,1    0     0 15016 /tmp/ibKpdj7k (deleted)
mysqld  13712 mysql    7u   REG    8,1    0     0 15018 /tmp/ibXBeg2u (deleted)
mysqld  13712 mysql   11u   REG    8,1    0     0 14979 /tmp/ib6ZuzwG (deleted)

Само че така и не разбрах, какво става с тези файлове ?

размонтирай /dev/sda3 и /dev/sdb1 и виж какво има в  /DATA и  /backup
същото можеш да провериш и ако някъде монтираш устройства за архивиране (провери си архивиращите скриптове)

топ 10 най-големи директории под текущата
и се разходи малко из дървото

ако имаш работещ Х пробвай с kDirStat

или
да търсиш големи файлове

DATA и Backup са други дискове, не е /dev/sda
Големи файлове (единични) няма.
Разхождал съм се из всички директори, коренови на руута
С МС, директно само с df . && du -shk.... нищо
Сумарно около 8Г заети
А сървъра спира заради недостатъчно свободно дисково пространство!
Сега пуснах да видя най-голямите директории, но не очаквам да излезе нещо....

DATA и Backup са други дискове, не е /dev/sda

много добре виждам че са на други дискове, но това е СЕГА.
Ако се е уляло монтирането на Backup например, нали се сещаш къде се е изсипал архива..., затова не се ослушвай ами провери.

И ко са ужас :D

Докато не видя изхода от командите по-долу тая тема заслужава златен медал по тролене :D :
du -sh .*
du -sh *
df -h


Иначе разсъждавате по интересен начин :D
"Free space leakage" - баси корпоративния израз. Звучи толкова high-tech и абстрактно, че чак имам чувството, че политам от липса на гравитация и съдържание :D . По-скоро нещо си дъмпи крашове като скрити файлове в root-a или имаш "изтрити" файове, който още се позват - правилно си се ориентирал с lsof. Може ли да видим целия изход на командата ( без параметри) ?

Ай, със здраве :)

DATA и Backup са други дискове, не е /dev/sda
Големи файлове (единични) няма.
Разхождал съм се из всички директори, коренови на руута
С МС, директно само с df . && du -shk.... нищо
Сумарно около 8Г заети
А сървъра спира заради недостатъчно свободно дисково пространство!
Сега пуснах да видя най-голямите директории, но не очаквам да излезе нещо....

Топър, ето едно обяснение на разликата между df и du

About du -s and df

Notice that du and df report on only the blocks allocated for data actually
written. The ls command reports slightly different results depending on the type
of file. See the section in this document called, "The ls command".

At AIX versions prior to 4.1, df reports its statistics in 1024-byte units and
du reports in 512-byte units. At AIX 4.1 and later, both df and du default to
512-byte units. The following discussion addresses df and du in AIX 4.x; thus
all units are in 512-byte blocks.

--------------------------------------------------------------------------------

The problem

Sometimes du and df are used to get a free block value: df is used to report the
total block count, and then the value returned by du -s /filesystem_path is
subtracted from that total to calculate the free block value. However, this
method of calculation yields a value that is greater than the free block value
reported by df.

For example, sample output from executing du -s /tmp is as follows:

   12920   /tmp

Sample output from executing df /tmp on the same system is as follows:
Filesystem    512-blocks      Free  %Used    Iused  %Iused  Mounted on
/dev/hd3           57344     42208    26%      391      4%  /tmp

Here, the <total from df> - <used from du> = <false free block count>: 57344 -
12920 = 44424.

44424 is greater than 42208. The reason for this discrepancy involves the
implementation of du and df.

du -s

du -s traverses the file tree, adding up the number of blocks allocated to each
directory, symlink, and file as reported by the stat() system call. This is how
du arrives at its total value.

df

df looks at the file system disk block allocation maps to arrive at its total
and free values.

--------------------------------------------------------------------------------

Why the numbers do not add up

The file system allocates some of the disk blocks in the file system to record
its data. This data is referred to as meta data. Meta data is not visible to
most user-level programs. Examples of meta data are inodes, disk maps, indirect
blocks, and super blocks.

du is an example of a user-level program that is not aware of file system meta
data, while df looks at the file system disk allocation maps and is aware of
file system meta data. df obtains the true file system statistics, whereas du
sees only a partial picture. For example, an empty 4MB JFS file system created
with frag=4096 and nbpi=4096 has the following meta data allocated:

   1  4k block for the LVM
   2  4k super blocks
   2  4k blocks for disk maps
   2  4k blocks for inode maps
   2  4k blocks for .indirect
   32 4k blocks for inodes
   -------------------------
   41 4k blocks for meta data on an empty 4MB file system

For AIX Version 4.x:
Executing du /foo returns output like the following:
   8       /foo/lost+found
   16      /foo

The sixteen 512-byte blocks reported by du on this empty file system are the
blocks used by the root directory.

To get the output from du to match that from df, we must add in the meta data.
First, convert 41 4K blocks to 512-byte units:

    41 * 8 = 328
    328(meta data) + 16(from du) = 344

So there are 344 512-byte blocks allocated on this empty file system. For
example:

    8192(total blocks) - 344(used from du + meta data) = 7848

This value does match the output from the free column reported by df /foo.

  Filesystem  512-blocks  Free   %Used   Iused   %Iused   Mounted on
  /dev/lv01         8192  7848      5%      16       2%   /foo

This calculation was easy to perform on an empty file system. However, on a
non-empty file system, the meta data for file indirect blocks comes into play
and such calculations are tedious and impractical.

In conclusion, du -s produces a value that reflects the number of disk blocks
that are allocated to files and directories. df reports on the actual allocation
state of the file system. The true allocation state includes both user data
(files and directories) plus meta data.

Another example that contributes to a difference between du and df is the
following:

  If someone is running an application with a file open in a directory and the
  open file is removed, the du output reflects a reduced size for this
  directory. However, df does not show a reduced size because all blocks in the
  file system remain allocated until the application that has the file open
  closes the file. After the file closure, df shows reduced usage for the file
  system.

--------------------------------------------------------------------------------

The ls command

The following compares ls output with that of du and df for sparse files.

ls gives data on individual files based on the difference between the end-of-file (the largest offset where data is written) and the beginning-of-file, whether or not blocks were actually allocated to the file. A 32MB file (as reported by ls) may not have 32MB of data written to it if the data is not written sequentially.
du shows the blocks actually allocated to an individual file.
df shows the blocks allocated in the entire file system, including inodes and other meta data.
An example sparse file can be created fairly easily. To do so, open the file, seek to a large address, and write some data. This can be demonstrated with the dd command, as follows:

Create a regular file.
    date > notsparse
    ls -l

The output of the ls command will be similar to the following:

    total 8
    -rw-r--r--   1 root     sys         29 Dec 21 08:12 notsparse

Use the fileplace command to see how many allocated and unallocated blocks are included in the file notsparse.

NOTE: Performance Analysis and Control Commands (perfagent.tools) must be installed for AIX Version 4.x.

    fileplace notsparse

The output for AIX Version 4.x will look similar to the following:

    File: notsparse  Size: 29 bytes  Vol: /dev/lv03
    Bkl Size: 4096  Frag size: 4096 Nfrags: 1 Compress: no
    Logical Fragment
    ----------------
    00716                   1 frags        4096 bytes,  100.0%

The du command also reflects how many 512-byte blocks a file occupies.
    du -rs *

Example output looks similar to the following:

    8 notsparse

Now create a sparse file using the regular file notsparse as input, as shown in the following:
    touch sparse.1
    dd if=notsparse of=sparse.1 seek=100

Example output looks similar to the following:

    dd: 0+1 records in.
    dd: 0+1 records out.

The dd command takes the data from the regular file and places it, in 100 512-byte blocks, into the sparse.1 file. Nothing is written to the initial 99 512-byte blocks. The following steps show the characteristics of the resulting file.

The ls command reports the distance from block zero to the last block in the file:
    ls -l

Example output looks similar to the following:

    total 16
    -rw-r--r--  1 root   sys       29 Dec 21 08:12 notsparse
    -rw-r--r--  1 root   sys    51229 Dec 21 08:13 sparse.1

The fileplace command accurately reports what blocks are unallocated and allocated. For example:
    fileplace sparse.1

Example output for AIX Version 4.1 looks similar to the following:

    File: sparse.1  Size: 51229 bytes Vol: /dev/lv03
    Blk Size: 4096  Frag Size: 4096  Nfrags: 1  Compress: no
    Logical Fragment
    ----------------
    unallocated               12 frags  49152 Bytes,  0.0%
    0000769                    1 frags   4096 Bytes, 100.0%

The du command reports the number of allocated blocks the file takes. For example:

    du -rs *

The example output looks similar to the following:

    8 notsparse
    8 sparse.1

Each command correctly reports the data that is specific to its intended purpose. ls shows the range of offsets where data can be read from or written to a file. Reading from an offset where no data is written makes it appear to be zero-filled. du and df report only blocks allocated for data actually written.

NOTE: For more information about sparse files see prism document, "About Sparse Files."

 изпразни ли Recycle Bin?

Цитат на: Topper в Feb 07, 2012, 00:33

DATA и Backup са други дискове, не е /dev/sda

много добре виждам че са на други дискове, но това е СЕГА.
Ако се е уляло монтирането на Backup например, нали се сещаш къде се е изсипал архива..., затова не се ослушвай ами провери.

Сега ти разбрах идеята, размонтирани:

du -sh /backup
0       /backup
 du -sh /DATA
0       /DATA
du -sh /tmp/
0       /tmp/

lsof -a +L1
COMMAND   PID USER   FD   TYPE DEVICE SIZE NLINK   NODE NAME
evlogd   6102 root  mem    DEL    0,6          0 458752 /SYSV00001a38
evlogd   6184 root  mem    DEL    0,6          0 458752 /SYSV00001a38
killproc 7957 root    0u   CHR  136,4          0      6 /dev/pts/4 (deleted)
killproc 7957 root    5u   CHR  136,4          0      6 /dev/pts/4 (deleted)

lsof е много голям, така че споделете идеята и какво търсим.
Може да направя дъмп и да го кача някъде, но далеч по-лесно ще е - мисля, че може да е еди-какво-си, виж това или онова.

шОшОн, впечатлен съм от проницателността ти, но не подхождай с идеята, че всички около теб са овце.
Можеше да видиш какви данни съм пуснал, а че също така съм правил du на всички директории в руута, както съм и написал, както и после отново постнах, но хайде да да ти изпълня заръката:

du -sh .*
du: `./media/cdrom': No medium found
391G    .

du -sh *
47G     DATA
0       abas-wine
1.7G    backup
103G    backupimap
6.7M    bin
11M     boot
393K    dev
87M     etc
253M    home
89M     lib
0       lost+found
du: `media/cdrom': No medium found
0       media
179G    mnt
193M    opt
907M    proc
73M     root
21M     sbin
4.0K    secrets.tdb
197K    share
465M    srv
0       sys
210M    tftpboot
335K    tmp
5.3G    usr
3.4G    var

df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              28G   28G  619M  98% /
tmpfs                1013M   16K 1013M   1% /dev/shm
/dev/sda3              70G   47G   24G  67% /DATA
/dev/sdb1             151G  1.7G  149G   2% /backup
/dev/sdb2             148G   47G   95G  33% /mnt/usb2
/dev/mapper/system-LogicalVolume01
                      500G  133G  368G  27% /mnt/usbbig
/mnt/usbbig/src       500G  133G  368G  27% /usr/src
/dev/mapper/system-backupimap
                      150G  103G   48G  69% /backupimap

Колкото до троловете, виждал съм доста хелпдеск вампири, които в реален проблем обясняват нещата със "срив" "бъг" и т.н. И изкарват в прадакшън обркъжение точно 3 месеца. Лични наблюдения.

изпразни ли Recycle Bin?

Ей не, не се бях сетил - аз там си държа като в архив файлове...  >:D

Цитат на: bot в Feb 07, 2012, 11:11

изпразни ли Recycle Bin?

Ей не, не се бях сетил - аз там си държа като в архив файлове...  >:D

bop_bop_mara в една тема преди доста време беше попитала кои файлове, къде е най-добре да съхраняваме, понеже някой се беше изказал, че в home не било надеждно.
Ето къде трябва да се съхраняват архивите - в кошчето :)

ок, идеята на лсоф-а е да намериш отворени файлове с брой на линковете към тях по-малък от 1, т.е. отворени и ънлинкнати. Ако не разбираш как би ти помогнало това, ти предлагам да направиш
touch /forcefsck
и да рестартираш, или да рестартираш в сингъл юзер и да пуснеш fsck на / и след това да репортнеш резултатите

Направих и чек в сингъл юзър (машината е VM и не е проблем) но нямаше нито грешки, нито видим ефект.
Даже два пъти!
А руута продължава да се пълни и машината ми спира. Ще пристъпя към екстенд, но принципно ме дразни проблема. И да няма решение....

Очаквам все пак смислени предложения.
Не може за едно нащо да се загубят 70% (19Гб) ей така!

Направих и чек в сингъл юзър (машината е VM и не е проблем) но нямаше нито грешки, нито видим ефект.
Даже два пъти!
А руута продължава да се пълни и машината ми спира. Ще пристъпя към екстенд, но принципно ме дразни проблема. И да няма решение....

Очаквам все пак смислени предложения.
Не може за едно нащо да се загубят 70% (19Гб) ей така!

пусни лога на Mysql за да видиш какви заявки се правят, защото май той е виновника с някакви картезиански истории :)

Абсолютно нищо  >:(

THIS is exactly why I like linux.... choices...

du -h

du -hs <directory>

du -s -c Folder

clear; for each in $(ls) ; do du -hs "$each" ; done

for each in bin etc initrd lost+found proc sbin sys usr boot lib opt root srv tmp var ; do du -hs "$each" ; done

tree -sd

Източник ($2)

Благодаря за подсказката, за 3-и път, ама още в анонса ги постнах резултатите.
Ако имаше решението в Гугъл, нямаше да питам тук.

шОшОн, впечатлен съм от проницателността ти, но не подхождай с идеята, че всички около теб са овце.

Аз просто така си говоря :)

Моля ви, МОЛЯ ВИ, заради спорта,
du -sh /.*

* (zvezda) НЕ хваща скрити фаилове! Много често ОС-ите си дъпмят core файлове в /. За това те помолих не за друго. И кога викаш е станало това? На 5ти?

find / -xdev -mtime -5 -type f -exec ls -l {} \; | sort -n -k 5

# Да ти кажа какво ще нaправи това:
- извади всички файлове докоснати последните 4 дена
 - прегледа само /
 - сортира по размер

Това са супер прости команди, но замисли се, закво да диря под вола теле, след като решението просто може да e толкова елементарно.

Pак казвам - * не хваща скрити файлове!

Моля те - малко доверие и копи/паста

Ами аз въпреки всичко изпълних командите и ги постнах, ама явно не обичаш да четеш.
Хайде да потретя тогава:

du -sh /.*
du: `/./media/cdrom': No medium found
341G    /.
du: `/../media/cdrom': No medium found

Големи файлове (даже стигнах най-малко 10мб) търсих още на сутринта - модифицирани, създадени, не само на руут дяла, а навсякъде, нямаше такива.
А модифицирани изобилно, мейл сървър е все пак това.

Ами аз въпреки всичко изпълних командите и ги постнах, ама явно не обичаш да четеш.
Хайде да потретя тогава:

Цитат

du -sh /.*
du: `/./media/cdrom': No medium found
341G    /.
du: `/../media/cdrom': No medium found

Големи файлове (даже стигнах най-малко 10мб) търсих още на сутринта - модифицирани, създадени, не само на руут дяла, а навсякъде, нямаше такива.
А модифицирани изобилно, мейл сървър е все пак това.

Огледай се за sparse файлове. И една (макар и малко вероятна) насока: http://bugs.mysql.com/bug.php?id=40847

информацията която ни се дава е очевидно филтрирана, така, че едва ли ще се сетим.
Например:

     179G    mnt

която никъде не се вижда като монтирана, а този рамер няма как да се побере в /. Кой знае още какво друго има за което си нямаме идея.

Което едва ли е от значение, но...

df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              28G   27G  1.7G  95% /
tmpfs                1013M   16K 1013M   1% /dev/shm
/dev/sda3              70G   48G   22G  69% /DATA
/dev/sdb1             151G  1.7G  149G   2% /backup
/dev/sdb2             148G   47G   95G  33% /mnt/usb2
/dev/mapper/system-LogicalVolume01
                      500G  133G  368G  27% /mnt/usbbig

Здравей.
Обърках командата ок. Признавам си брез бой. Може ли
ls -la / или простод а те питам сигурен ли си че няма скрити файлове в / . 100% сигурен!
много бих се радвал на еднин много ограничен user акаунт ( на лс ). Ако ти стиска де...

Не, нещо не съм убеден във възможностите ти.
Дали съм убеден? Ами да взема да хвърля боб освен, след като командите нищо не показват.

OffLКакто и да е, уверих се за пореден път в общността тук и смятам отново за няколко години да не питам нищо.
Обещавам.

В предишните постове спомена, че си проверил файловата система, но ако искаш направи това пак с ncdu.
Програмата е лека и бърза, показва общо използвано място и подробно в коя директория колко място се ползва. В посочения линк може да видиш скрийншотове:
http://dev.yorhel.nl/ncdu/scr ($2)

Благодаря, това ще е полезно.
Макар че едва ли ще изскочи нещо - същото е като du, но ще преровя пак и с него.
Пак благодаря, едно от малкото смислени мнения!

Както и очаквах, резултатие са същите:

  179.2GiB [ 46.1% ##########] /mnt
  102.0GiB [ 26.3% #####     ] /backupimap
.  49.0GiB [ 12.6% ##        ] /media
   47.2GiB [ 12.2% ##        ] /DATA
    4.8GiB [  1.2%           ] /usr
    2.3GiB [  0.6%           ] /var
    1.7GiB [  0.4%           ] /backup
  897.5MiB [  0.2%           ] /proc
  414.5MiB [  0.1%           ] /srv
  240.9MiB [  0.1%           ] /home
  207.6MiB [  0.1%           ] /tftpboot
  175.9MiB [  0.0%           ] /opt
   85.5MiB [  0.0%           ] /lib
   84.2MiB [  0.0%           ] /etc
   62.7MiB [  0.0%           ] /root
   20.5MiB [  0.0%           ] /sbin
   10.9MiB [  0.0%           ] /boot
    6.4MiB [  0.0%           ] /bin
    6.2MiB [  0.0%           ] /sys
    2.7MiB [  0.0%           ] /tmp
  390.0KiB [  0.0%           ] /dev
  127.3KiB [  0.0%           ] /share
  696.0  B [  0.0%           ]  secrets.tdb
e  48.0  B [  0.0%           ] /lost+found
@  21.0  B [  0.0%           ]  abas-wine

 Total disk usage: 391.8GiB  Apparent size: 388.4GiB

19Gb хич ги няма :(

.....

19Gb хич ги няма :(

Погледни това, мисля че това е твоя случай:
http://itsecureadmin.com/2010/02/mysql-tmp-usage-with-optimize-table-command/

Ако проблема ти е в това друго решение е да дефинираш в my.cnf друга файлова система за tmpdir
tmpdir=......

Никъде не си споменал тази директория:

102.0GiB [ 26.3% #####     ] /backupimap

Покажи изхода от командите:
cat /etc/fstab
ls /mnt/
ls /backupimap
ls /media
покажи съдържанието и на файла, от който автоматично mount-ваш другите дискове, ако не е от /etc/fstab (прим. cat /etc/init.d/boot.local)

Покажи изхода от командите:
cat /etc/fstab
ls /mnt/
ls /backupimap
ls /media
покажи съдържанието и на файла, от който автоматично mount-ваш другите дискове, ако не е от /etc/fstab (прим. cat /etc/init.d/boot.local)

съдържанието на тези директории няма НИЩО общо с проблема!!!

  897.5MiB [  0.2%           ] /proc

такова нещо не съм виждал досега ****
интересно дали ако рестартираш в сингъл юзер и пуснеш дф след фсцк кво ше излезе...

Редактирано от bop_bop_mara.

bop_bop_mara ае да не ми пипаш постовете, никъде в правилата не пише нищо даващо ти право да ме мародерираш така...

Цитат на: mystical в Feb 08, 2012, 16:26

Покажи изхода от командите:
cat /etc/fstab
ls /mnt/
ls /backupimap
ls /media
покажи съдържанието и на файла, от който автоматично mount-ваш другите дискове, ако не е от /etc/fstab (прим. cat /etc/init.d/boot.local)

съдържанието на тези директории няма НИЩО общо с проблема!!!

Да Капитане, това се опитвам от началото да кажа - няма нищо общо с проблема!
Имаше един смислен съвет на колегата Аероплан:

размонтирай /dev/sda3 и /dev/sdb1 и виж какво има в  /DATA и  /backup
същото можеш да провериш и ако някъде монтираш устройства за архивиране (провери си архивиращите скриптове)

Но и това не е случая (да се крият файлове в маунт директориите)
Както и спарс файлове не са, както и не е проблема на дъмповете на MySQL-а.
Най-малкото /tmp ми е на друг дял, доста голям и доста свободен.

du -sh /proc/
915M    /proc/

като най-голямият файл е

-r--------    1 root    root    897M Feb  8 18:01 kcore

mail:/etc # lsof | grep -i delet
mailmanct  5304 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5305 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5306 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5307 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5308 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5309 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5310 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5311 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
python     5312 mailman    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
mailgraph 15216    root    6u   CHR      136,6                    8 /dev/pts/6 (deleted)
mysqld_sa 27191    root    6u   CHR      136,1                    3 /dev/pts/1 (deleted)
mysqld    27225   mysql    1w   REG        8,1      4371      17753 /var/lib/mysql/mysqld.log.1 (deleted)
mysqld    27225   mysql    2w   REG        8,1      4371      17753 /var/lib/mysql/mysqld.log.1 (deleted)
mysqld    27225   mysql    6u   CHR      136,1                    3 /dev/pts/1 (deleted)
mysqld    27225   mysql    9u   REG        8,1         0      29214 /tmp/ibMQ1URQ (deleted)
mysqld    27225   mysql   10u   REG        8,1         0      29276 /tmp/ibRiySQO (deleted)
mysqld    27225   mysql   14u   REG        8,1         0      29331 /tmp/ibiPH5VM (deleted)

Скрипта, който монтира допълнителните дялове (пуска се след всичко останало, заради проблеми с USB дискове и LVM)

mount /dev/sdb1            /backup      -t auto
mount /dev/sdb2            /mnt/usb2    -t auto
mount /dev/system/LogicalVolume01 /mnt/usbbig -t auto
mount --bind /mnt/usbbig/src /usr/src
mount --bind /mnt/usbbig/galz /srv/www/htdocs/gallery/pictures
mount /dev/system/backupimap /backupimap -t auto

/etc/fstab

/dev/sda1       /       reiserfs        acl,user_xattr 1 1
/dev/sda3       /DATA   reiserfs        defaults 1 2
/dev/sda2       swap    swap    pri=42 0 0
devpts  /dev/pts        devpts  mode=0620,gid=5 0 0
proc    /proc   proc    defaults 0 0
usbfs   /proc/bus/usb   usbfs   noauto 0 0
sysfs   /sys    sysfs   noauto 0 0
/dev/cdrom      /media/cdrom    subfs   fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0

Някакви log-bin да имаш конфигурирани? Ако да опитай се да ги изместиш в поддиректория на /tmp

Някакви log-bin да имаш конфигурирани? Ако да опитай се да ги изместиш в поддиректория на /tmp

tmpfs говори ли ти нещо?

Цитат на: romeo_ninov в Feb 08, 2012, 18:24

Някакви log-bin да имаш конфигурирани? Ако да опитай се да ги изместиш в поддиректория на /tmp

tmpfs говори ли ти нещо?

На мен ми говори, но явно на вас  /proc не ви говори много
И може би имам специална причина да питам за двоичните логове

Някакви log-bin да имаш конфигурирани? Ако да опитай се да ги изместиш в поддиректория на /tmp

Не Капитане, нямам двоични логве.
А и въобще като MySQL сървър не е натоварен въобще, има 2ГБ бази.

Очевидно акредитацията ми е 0, но ето още една идея:
- имаш някава директория: примерно /
- имаш точка на монтиране примерно /mnt
- имаш два логически диска - първо монтираш /
- изиспваш 19 ГБ файлове в /mnt
- монтираш втория празен диск в /mnt

Воала... df -h ти показва, че всичко е пълно. du -h / не намира нищо...

Не казвам че имам идея как може да се е случило, НО е възможен вариант... Може лесно да тестваш:

mkdir /chroot/
mount --bind / /chroot

така :
1) елиминираш възможност от неизтрити файлове, защото в новото дърво говорим за изцяло различни inodes, и ИМА смисъл да пуснеш df -h наново.
2) може да прегледаш САМО / и те съветвам да пуснеш пак всичките си проверки.

Просто мойте 2 стинки.

Това го обсъдихме вече, мисля 3 пъти.
Няма резултат, нищо не изскочи.

Скрипта, който монтира допълнителните дялове (пуска се след всичко останало, заради проблеми с USB дискове и LVM)

Цитат

mount /dev/sdb1            /backup      -t auto
mount /dev/sdb2            /mnt/usb2    -t auto
mount /dev/system/LogicalVolume01 /mnt/usbbig -t auto
mount --bind /mnt/usbbig/src /usr/src
mount --bind /mnt/usbbig/galz /srv/www/htdocs/gallery/pictures
mount /dev/system/backupimap /backupimap -t auto

/etc/fstab

Цитат

/dev/sda1       /       reiserfs        acl,user_xattr 1 1
/dev/sda3       /DATA   reiserfs        defaults 1 2
/dev/sda2       swap    swap    pri=42 0 0
devpts  /dev/pts        devpts  mode=0620,gid=5 0 0
proc    /proc   proc    defaults 0 0
usbfs   /proc/bus/usb   usbfs   noauto 0 0
sysfs   /sys    sysfs   noauto 0 0
/dev/cdrom      /media/cdrom    subfs   fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0

Според това, което си дал като информация горе, в /media не трябва да има товкова информация:

49.0GiB [ 12.6% ##        ] /media

От досегашни проблеми с линукс, стигнах до извода, че всеки проблем в него се дължи на нещо просто, но въпроса е да откриеш източника.
Ти знаеш по-добре от всички участници във форума какво има стартирано на машината, като приложения и скриптове.  Не игнорирай нищо и прегледай всичко на ново.

Ето нещо за сравнение:

    9.0GiB  /opt
    3.8GiB  /home
    3.0GiB  /usr
    1.9GiB  /var
  125.4MiB  /lib
   21.5MiB  /boot
    7.0MiB  /etc
    5.6MiB  /bin
    4.0MiB  /sbin
    3.6MiB  /lib32
    2.3MiB  /root
    1.1MiB  /Steam
  196.0kiB  /tmp
  112.0kiB  /dev
e  16.0kiB  /lost+found
    8.0kiB  /media
e   4.0kiB  /mnt
e   4.0kiB  /selinux
e   4.0kiB  /srv
    0.0  B  /proc
    0.0  B  /sys
@   0.0  B   initrd.img
@   0.0  B   vmlinuz
@   0.0  B   lib64

Има пуснати Apache,MySql, 4-CounterStrike  сървъра.

Успех!

Така го е сметнал ncdu!

du -sh /media/.*
du: `/media/./cdrom': No medium found
du: `/media/./usb-2GEWL9A1:0:0:0p1': No such file or directory
du: `/media/./usb-2GEWL9A1:0:0:0p2': No such file or directory
du: `/media/./usb-2GEWL9A1:0:0:0p3': No medium found
du: `/media/./usb-2GEWL9A1:0:0:0p5': No medium found
0       /media/.
du: `/media/../media/cdrom': No medium found
du: `/media/../media/usb-2GEWL9A1:0:0:0p1': No such file or directory
du: `/media/../media/usb-2GEWL9A1:0:0:0p2': No such file or directory
du: `/media/../media/usb-2GEWL9A1:0:0:0p3': No medium found
du: `/media/../media/usb-2GEWL9A1:0:0:0p5': No medium found
393G    /media/..

Е какво стана - беше присмех, беше "и ся к'во" ама разумни мисли чух само две-три, за съжаление не ми помогнаха много, но благодаря.

За тези, които може би могат и имат време да помогнат, качвам една снимка:
(http://img685.imageshack.us/img685/7283/diskmonthpng211.png) ($2)

ми на два пъти искам да кажеш дф и ду в сингъл юзер след фсцк дали има неква разлика и ти два пъти не го правиш...
най-добре да няма нищо маунтнато и нищо пуснато

Не съм те разбрал, че иска du+df в сингъл юзър :(
Снощи го екстенднах с +20Гб, днес сутринта го намирам 100% пълен ОТНОВО :(

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              48G   48G  6.4M 100% /
/dev/sda3              70G   49G   22G  70% /DATA
/dev/mapper/system-LogicalVolume01
                      500G  131G  370G  27% /mnt/usbbig
/dev/sdb1             151G  1.6G  149G   2% /backup
/dev/mapper/system-backupimap
                      150G  102G   49G  68% /backupimap

Single user boot:
du -sh /.*
9Gb

df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              48G   48G  6.4M 100% /
/dev/sda3              48G   48G  6.4M 100% /DATA
/dev/mapper/system-LogicalVolume01
                      48G   48G  6.4M 100% /mnt/usbbig
/dev/sdb1             48G   48G  6.4M 100% /backup
/dev/mapper/system-backupimap
                      48G   48G  6.4M 100% /backupimap

Не знам дали остава друго, освен да смениш файловата система или да обновиш ядрото, или и двете. На мен, като очаквания, по- ми харесва първото.

И как да стане това най-безболезнено, като идея ?
Нов дял ext3 и dd, последвано от grub repair ?

Сега пуснах Live CD (Knopix) и fsck --rebuild-tree --rebuild-sb пък да видим, ще постна резултатите.

пусни един
  iotop
(трябва да го инсталираш първо) и виж кой най-много пише по диска

Не посрещам изискванията, а и ще е доста сложно на пощенски/MySQL/LDAP и още доста услуги, сървър.

Огледай по скриптовете навсякъде където се споменава /dev/null дали няма някоя запетайка или шпация в повече. Пробвай и дали нямаш новоизлюпен файл nuull, nnull, nul или нещо подобно.
Много е тъпо - знам, ама ефекта е точно който описваш.

Проблема е решен:
1.Екстенд с 20Г
2.reserfsck --rebuild tree
имаше 2 (две) грешки, но понеже бе в сингъл юзър, не можех да ги копирам.
За сега 2-3 дни няма "изчезване"
Друго което направих е да сложа накрая swap партишъна, защото в Linuxquestion имаше такъв съвет при такъв проблем. Не смятам, че това е било, но .... бях в чудо.