Hm, ok, forget about the shell options / shopt - the globbing only matters if you are using patterns (like *), which you are not in your described use of du. So it won't make any difference.

When using df to see how much room you have got left, keep in mind that often some fraction of each filesystem is reserved for the super-user (5 % is a commond default) - so you can have "plenty" of space free according to df, yet at the same time be unable to write anything as a non-root user. But as your df looks pretty normal, and particularly you've got more than plenty of space left on / this probably is not an issue here.

What does df tell you after keeping it running over night?

Kind regards,

Helmut.

--
+------------------------+
| Helmut Walle           |
| [email protected] |
| +64-3-388 39 54        |
+------------------------+

On Thu, 17 May 2012, Bevan wrote:

haven't run shopt -s dotglob yet but this is the output so far

also note this only happens after i leave the computer on when i go to bed and 
in the morning it starts to fill up after a reboot its good for the day.

df

/dev/sdb2       38973500  30982860   6037568  84% /
udev             4046232         4   4046228   1% /dev
tmpfs            1635200      1128   1634072   1% /run
none                5120         0      5120   0% /run/lock
none             4087992       228   4087764   1% /run/shm
/dev/sdb3       43855316  23531724  18126344  57% /home
/dev/sdc1      976758780 909109832  67648948  94% /windows1
/dev/sda2      102294524  76498080  25796444  75% /winsys
/dev/sdb1      385987580 367268972  18718608  96% /windows2
/dev/sda3      385987572 345606924  40380648  90% /windows3
/dev/sdd1        7811088   6632896   1178192  85% /media/TSB USB DRV


ls |grep -v Volumes> temp

cat temp |xargs du -sk |sort -n

0    initrd.img
0    initrd.img.old
0    proc
0    sys
0    vmlinuz
0    vmlinuz.old
4    dev
4    duresults
4    lib64
4    selinux
4    temp
4    webmin-setup.out
8    mnt
12    srv
16    lost+found
1224    run
3384    lib32
8800    sbin
8916    bin
14488    root
23532    etc
48924    boot
146796    tmp
391072    opt
410396    lib
4328684    var
6632904    media
7250012    usr
22739196    home
75818184    winsys
345111319    windows3
366813683    windows2
908534993    windows1

ran the command a bit later again

0    initrd.img
0    initrd.img.old
0    proc
0    sys
0    vmlinuz
0    vmlinuz.old
4    dev
4    duresults
4    lib64
4    selinux
4    temp
4    webmin-setup.out
8    mnt
12    srv
16    lost+found
1224    run
3384    lib32
8800    sbin
8916    bin
14488    root
23532    etc
48924    boot
146796    tmp
391072    opt
410396    lib
4332820    var
6632904    media
7250012    usr
22740540    home
75818184    winsys
345111319    windows3
366813683    windows2
908534993    windows1



Regards

Bevan

In a world without fences and walls, who needs Gates and Windows?



On 16 May 2012 00:23, Helmut Walle <[email protected]> wrote:

      One more thing to keep in mind, and this may have been mentioned 
before... depending on how you are invoking du you may be missing files or 
directories due to shell
      globbing. For example, if you are running du (or any command for that 
matter) from bash as it comes on most systems like this

      du -s *

      to obtain summary disk usage for everything, I would expect that it won't 
scan anything with a name beginning with a period '.' This is due to the fact 
that bash
      expands * to pretty much everything, except names starting with a period.

      To test this, try

      ls *

      in a location where you have some files or directories with names 
beginning with a period, and you may find that they won't be listed. This 
behaviour of bash is
      configurable by setting the shell option "dotglob" by executing this:

      shopt -s dotglob

      which will make bash expand * to everything, also including names 
starting with a period. You can check the shell options with just

      shopt

      I am not sure whether this is what's missing in your case, Bevan, but it 
is one possible way of missing files and directories.

      If you are using some other shell, this may all be different, but the key 
point is that shells may perform some kind of name expansion, and this is often 
different
      from what you would expect if you are thinking along the lines of regular 
expressions.

      Kind regards,

      Helmut.

      --
      +------------------------+
      | Helmut Walle           |
      | [email protected] |
      | +64-3-388 39 54        |
      +------------------------+

      On Tue, 15 May 2012, Nick Rout wrote:

            On Tue, May 15, 2012 at 12:01 PM, Nick Rout <[email protected]> 
wrote:
                  On Tue, May 15, 2012 at 10:59 AM, Bevan <[email protected]> 
wrote:
                        but cant find any other source that would fill up the 
root drive. note my
                        home parition is a separate partition and i have three 
ntfs partitions (
                        which i am attempting to condense and move over to ext4 
partition


                  Well you need to find which file(s) are growing.

                  cd /
                  sudo du --max-depth=1 -x

                  Run it once, wait a while and run it again. Compare. The 
directory
                  which is filling up will be obvious. cd to it and run that 
command
                  again. rinse and repeat.

                  Then go that directory


            oops that last line shouldn't be there. By the way the -x excludes
            other file systems, so your /home and /proc and /sys should not be
            scanned.
            _______________________________________________
            Linux-users mailing list
            [email protected]
            http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

      _______________________________________________
      Linux-users mailing list
      [email protected]
      http://lists.canterbury.ac.nz/mailman/listinfo/linux-users




_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

Reply via email to