What is taking up so much space on my disk, beside the filesystem?












20















I have only one disk in my computer, a 80 GB SSD. It is formatted as a single ext4 partition (no swap), and all the usual folders are installed on it (I keep lots of data on external media, but /home and all the rest is on the SSD).



Today I booted it and I got a message that the drive is full. I opened Disk Usage Analyzer to look at what takes up space. It insists that 67.8 GB of the disk are used, and that / is taking up 36.4 GB. Which leads to the question, where are the missing 30 GB, if not on the file system?!



Just to have a comparison, I added up all the sizes of all readable folders listed in Nautilus as subfolders of / (including the hidden ones). I got 20.9 GB. Trash was unreadable, but I know it has 16.2 GB, so the sum is 36.1 GB, around the same as what Disk Usage Analyzer is reporting. There were some system folders which were unreadable, like proc, but I doubt that they add up to 30 GB - else it wouldn't be possible to install Ubuntu on small disks, and I've seen it run on 2.5 GB. I think they must be the 0.3 GB difference between my calculation and the Disk Usage Analyzer's report.



So I'd like to know, what is eating up these 30 GB and how do I get it to free them?



alt text



Edit with answers to CYREX's questions





  1. Booted from Ubuntu 10.10 64 bit live CD (same as my system).



    fsck result:



    root@ubuntu:~# fsck /dev/sda1
    fsck from util-linux-ng 2.17.2
    e2fsck 1.41.12 (17-May-2010)
    /dev/sda1: clean, 265956/4890624 files, 18073343/19537408 blocks



  2. Booted from the SDD. Emptied the trash, and the 16 GB from there are now free. The 30 GB are still missing.



    alt text




  3. I am not experienced enough to know what counts as weird in a log. Here are my messages log and my syslog since last boot, maybe you can find something in them:




    • http://pastebin.com/FHrrV1rR

    • http://pastebin.com/FK8TmZbc




  4. Here it got really strange. I plugged in an external 500 GB HDD. Disk Usage Analyzer overreported the available space, then showed space missing (76 GB used, but only 24 in folders).



    alt text




Booted again from the LiveCD, started the Disk Usage Analyzer from it and got the same results as from the installed Ubuntu, within 1-2 GB.



Edit with answer to CodeMonk



That would have been a nice solution, but the partition is really 80 GB - I mean 74 GB + marketing "error", anyway the whole disk is formatted. It also shows that over 50 GB are used - so where are the 30 GB if not in files and folders?



alt text
GParted also reports the correct size of the external HDD.



alt text










share|improve this question

























  • Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

    – João Pinto
    Dec 15 '10 at 10:42








  • 3





    By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

    – msw
    Dec 15 '10 at 13:00











  • Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

    – LiveWireBT
    Oct 8 '12 at 21:01
















20















I have only one disk in my computer, a 80 GB SSD. It is formatted as a single ext4 partition (no swap), and all the usual folders are installed on it (I keep lots of data on external media, but /home and all the rest is on the SSD).



Today I booted it and I got a message that the drive is full. I opened Disk Usage Analyzer to look at what takes up space. It insists that 67.8 GB of the disk are used, and that / is taking up 36.4 GB. Which leads to the question, where are the missing 30 GB, if not on the file system?!



Just to have a comparison, I added up all the sizes of all readable folders listed in Nautilus as subfolders of / (including the hidden ones). I got 20.9 GB. Trash was unreadable, but I know it has 16.2 GB, so the sum is 36.1 GB, around the same as what Disk Usage Analyzer is reporting. There were some system folders which were unreadable, like proc, but I doubt that they add up to 30 GB - else it wouldn't be possible to install Ubuntu on small disks, and I've seen it run on 2.5 GB. I think they must be the 0.3 GB difference between my calculation and the Disk Usage Analyzer's report.



So I'd like to know, what is eating up these 30 GB and how do I get it to free them?



alt text



Edit with answers to CYREX's questions





  1. Booted from Ubuntu 10.10 64 bit live CD (same as my system).



    fsck result:



    root@ubuntu:~# fsck /dev/sda1
    fsck from util-linux-ng 2.17.2
    e2fsck 1.41.12 (17-May-2010)
    /dev/sda1: clean, 265956/4890624 files, 18073343/19537408 blocks



  2. Booted from the SDD. Emptied the trash, and the 16 GB from there are now free. The 30 GB are still missing.



    alt text




  3. I am not experienced enough to know what counts as weird in a log. Here are my messages log and my syslog since last boot, maybe you can find something in them:




    • http://pastebin.com/FHrrV1rR

    • http://pastebin.com/FK8TmZbc




  4. Here it got really strange. I plugged in an external 500 GB HDD. Disk Usage Analyzer overreported the available space, then showed space missing (76 GB used, but only 24 in folders).



    alt text




Booted again from the LiveCD, started the Disk Usage Analyzer from it and got the same results as from the installed Ubuntu, within 1-2 GB.



Edit with answer to CodeMonk



That would have been a nice solution, but the partition is really 80 GB - I mean 74 GB + marketing "error", anyway the whole disk is formatted. It also shows that over 50 GB are used - so where are the 30 GB if not in files and folders?



alt text
GParted also reports the correct size of the external HDD.



alt text










share|improve this question

























  • Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

    – João Pinto
    Dec 15 '10 at 10:42








  • 3





    By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

    – msw
    Dec 15 '10 at 13:00











  • Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

    – LiveWireBT
    Oct 8 '12 at 21:01














20












20








20


4






I have only one disk in my computer, a 80 GB SSD. It is formatted as a single ext4 partition (no swap), and all the usual folders are installed on it (I keep lots of data on external media, but /home and all the rest is on the SSD).



Today I booted it and I got a message that the drive is full. I opened Disk Usage Analyzer to look at what takes up space. It insists that 67.8 GB of the disk are used, and that / is taking up 36.4 GB. Which leads to the question, where are the missing 30 GB, if not on the file system?!



Just to have a comparison, I added up all the sizes of all readable folders listed in Nautilus as subfolders of / (including the hidden ones). I got 20.9 GB. Trash was unreadable, but I know it has 16.2 GB, so the sum is 36.1 GB, around the same as what Disk Usage Analyzer is reporting. There were some system folders which were unreadable, like proc, but I doubt that they add up to 30 GB - else it wouldn't be possible to install Ubuntu on small disks, and I've seen it run on 2.5 GB. I think they must be the 0.3 GB difference between my calculation and the Disk Usage Analyzer's report.



So I'd like to know, what is eating up these 30 GB and how do I get it to free them?



alt text



Edit with answers to CYREX's questions





  1. Booted from Ubuntu 10.10 64 bit live CD (same as my system).



    fsck result:



    root@ubuntu:~# fsck /dev/sda1
    fsck from util-linux-ng 2.17.2
    e2fsck 1.41.12 (17-May-2010)
    /dev/sda1: clean, 265956/4890624 files, 18073343/19537408 blocks



  2. Booted from the SDD. Emptied the trash, and the 16 GB from there are now free. The 30 GB are still missing.



    alt text




  3. I am not experienced enough to know what counts as weird in a log. Here are my messages log and my syslog since last boot, maybe you can find something in them:




    • http://pastebin.com/FHrrV1rR

    • http://pastebin.com/FK8TmZbc




  4. Here it got really strange. I plugged in an external 500 GB HDD. Disk Usage Analyzer overreported the available space, then showed space missing (76 GB used, but only 24 in folders).



    alt text




Booted again from the LiveCD, started the Disk Usage Analyzer from it and got the same results as from the installed Ubuntu, within 1-2 GB.



Edit with answer to CodeMonk



That would have been a nice solution, but the partition is really 80 GB - I mean 74 GB + marketing "error", anyway the whole disk is formatted. It also shows that over 50 GB are used - so where are the 30 GB if not in files and folders?



alt text
GParted also reports the correct size of the external HDD.



alt text










share|improve this question
















I have only one disk in my computer, a 80 GB SSD. It is formatted as a single ext4 partition (no swap), and all the usual folders are installed on it (I keep lots of data on external media, but /home and all the rest is on the SSD).



Today I booted it and I got a message that the drive is full. I opened Disk Usage Analyzer to look at what takes up space. It insists that 67.8 GB of the disk are used, and that / is taking up 36.4 GB. Which leads to the question, where are the missing 30 GB, if not on the file system?!



Just to have a comparison, I added up all the sizes of all readable folders listed in Nautilus as subfolders of / (including the hidden ones). I got 20.9 GB. Trash was unreadable, but I know it has 16.2 GB, so the sum is 36.1 GB, around the same as what Disk Usage Analyzer is reporting. There were some system folders which were unreadable, like proc, but I doubt that they add up to 30 GB - else it wouldn't be possible to install Ubuntu on small disks, and I've seen it run on 2.5 GB. I think they must be the 0.3 GB difference between my calculation and the Disk Usage Analyzer's report.



So I'd like to know, what is eating up these 30 GB and how do I get it to free them?



alt text



Edit with answers to CYREX's questions





  1. Booted from Ubuntu 10.10 64 bit live CD (same as my system).



    fsck result:



    root@ubuntu:~# fsck /dev/sda1
    fsck from util-linux-ng 2.17.2
    e2fsck 1.41.12 (17-May-2010)
    /dev/sda1: clean, 265956/4890624 files, 18073343/19537408 blocks



  2. Booted from the SDD. Emptied the trash, and the 16 GB from there are now free. The 30 GB are still missing.



    alt text




  3. I am not experienced enough to know what counts as weird in a log. Here are my messages log and my syslog since last boot, maybe you can find something in them:




    • http://pastebin.com/FHrrV1rR

    • http://pastebin.com/FK8TmZbc




  4. Here it got really strange. I plugged in an external 500 GB HDD. Disk Usage Analyzer overreported the available space, then showed space missing (76 GB used, but only 24 in folders).



    alt text




Booted again from the LiveCD, started the Disk Usage Analyzer from it and got the same results as from the installed Ubuntu, within 1-2 GB.



Edit with answer to CodeMonk



That would have been a nice solution, but the partition is really 80 GB - I mean 74 GB + marketing "error", anyway the whole disk is formatted. It also shows that over 50 GB are used - so where are the 30 GB if not in files and folders?



alt text
GParted also reports the correct size of the external HDD.



alt text







disk-usage






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 6 '18 at 13:19









muru

1




1










asked Dec 14 '10 at 22:54









rumtschorumtscho

7012925




7012925













  • Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

    – João Pinto
    Dec 15 '10 at 10:42








  • 3





    By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

    – msw
    Dec 15 '10 at 13:00











  • Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

    – LiveWireBT
    Oct 8 '12 at 21:01



















  • Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

    – João Pinto
    Dec 15 '10 at 10:42








  • 3





    By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

    – msw
    Dec 15 '10 at 13:00











  • Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

    – LiveWireBT
    Oct 8 '12 at 21:01

















Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

– João Pinto
Dec 15 '10 at 10:42







Sometimes is best to not trust on GUI tools, open a terminal and run, get a summarized report of used space per dir on the root: sudo du -sm /*

– João Pinto
Dec 15 '10 at 10:42






3




3





By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

– msw
Dec 15 '10 at 13:00





By not expanding the Disk Usage Analyzer entry for / in your first and second screenshots, you've blinded yourself (and us) to the sizes of all the subordinate directories which the ring chart clearly shows as being occupied by something. It could be something as simple as /var/log/syslog being filled with some hugely complaining hardware, but we need that data.

– msw
Dec 15 '10 at 13:00













Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

– LiveWireBT
Oct 8 '12 at 21:01





Have you tried looking for the logfiles? I remember I had my KVM switch and wireless keyboard not playing nice together after a reboot which caused a logfile to grow and filling up all the space (after two days). Replugging the device helped. May be different for your server, but hopefully gives you a hint.

– LiveWireBT
Oct 8 '12 at 21:01










7 Answers
7






active

oldest

votes


















33














If you use Disk Analyzer as a normal user there can be some files that you can't access or see. You can try to start it with superuser privileges. Open a terminal, or press ALT+F2 and type:



gksudo baobab


Baobab is the geeky name of the Disk Analyzer if you are wondering. Maybe it can now show you where those missing megabytes are.






share|improve this answer





















  • 1





    Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

    – Yufenyuy Veyeh Dider
    Feb 6 '18 at 15:33



















17














I solved it - thanks to all your advice, especially that of Javier Riveira, who suggested running Disk Analyzer with sudo rights (I didn't know this can have influence on the results).



I have Crashplan, and it is making backups to some of the external drives. So there is a backup set which goes to Milly, and another one which goes to Sto_Lat, once every 15 minutes (these are the names of the external drives). When I have at some point started the computer without these drives, Crashplan has found no folders under /media/Milly and /media/Sto_Lat, so it has just created them and has written backups to them.



For some reason, Disk Analyzer does not show these folders when started without sudo. Nautilus shows them, but lists the size of /media at 16 KB, when it is actually 30 GB.



I only noticed this when I dismounted all external drives, including Milly and Sto_Lat, and started gksudo baobab. Then I saw my external drives where there should be none - but not all of them but only the backup targets - and realised that these are not mounted drives, but eponymous folders created by Crashplan. There must be something weird going on when I mount the drive at the same name as the existing folder, I wonder why I don't get an error message or something...



BTW, this also solves why Disk Analyzer shows the sizes of Milly at 530 GB instead of 500 GB - these are the "missing" 30 GB, it counts the folder and the real drive together.



Now I only need a way to delete the folders without breaking Crashplan or remaining without backups.






share|improve this answer


























  • You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

    – Jorge Castro
    Dec 15 '10 at 21:17











  • This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

    – Michael Robinson
    Aug 31 '13 at 16:51











  • The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

    – arielf
    Sep 7 '15 at 1:36











  • @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

    – rumtscho
    Sep 7 '15 at 8:06











  • Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

    – arielf
    Sep 7 '15 at 21:23





















5














You can use the Disk Usage Analyzer to scan your directories and see where your space is going on the filesystem.



alt text



As for not being able to see 30GB of your disk, open up GParted and see how the space is allocated on the disk. It may be that your partition scheme isn't what you thought it was.



GParted






share|improve this answer
























  • GParted was a good idea, but the mystery remains, see screenshot

    – rumtscho
    Dec 15 '10 at 1:01











  • That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

    – Nick Pascucci
    Dec 15 '10 at 3:25



















4














You can use du to show this:



cd /
sudo du -hcsx .[!.]* * | sort -rh | head


or



sudo du -hcsx * | sort -rh | head


This will show what is using the most space.






share|improve this answer

































    3














    As default there are 10% of your disk space reserved for the root user. You can change that using sudo tune2fs -m %percentage %device. In your case that would be sudo tune2fs -m 1 /dev/cciss/c0d0p1 for reducing the reservation to 1%. You can set it to any other number you like but I would not recommend 0%.






    share|improve this answer
























    • Is the 'sudo du -chs /' results anything to worry about?

      – dannymcc
      Oct 8 '12 at 9:25











    • I don't know but if you don't have any other problems I wouldn't mind ;-)

      – André Stannek
      Oct 8 '12 at 9:28



















    1














    Do the following at let me know how it went:




    1. Insert a LiveCd and fsck your /dev/sda1

    2. Clean your Trash Can.

    3. See the Log File Viewer for weird stuff that is happening.

    4. Test (If you can) with a normal HDD (Not SSD). Just to remove that option.


    Let me know how it went.






    share|improve this answer
























    • Posted the info you requested, see edit in the question.

      – rumtscho
      Dec 15 '10 at 1:01



















    1














    I really don't know if this helps you, but in my case I also experienced that, my HDD was loosing free space over time without a reason. It turned out that the default settings in synaptic package manager was also a contributor to that. The default settings in the preferences, under the file tab will instruct synaptic to keep all downloaded packages in the cache. Over the time that can accumulate a nice mountain of files.
    I changed the settings to delete downloaded packages after installation. That helped to recover quite a nice amount of free space.



    Again I'm really not sure if that helps in your case, but you might check the synaptic cache, maybe that's full with files that are obsolete.






    share|improve this answer



















    • 1





      interesting to know, but this cache would be counted as part of the filesystem.

      – rumtscho
      Dec 15 '10 at 20:55











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "89"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f17467%2fwhat-is-taking-up-so-much-space-on-my-disk-beside-the-filesystem%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    7 Answers
    7






    active

    oldest

    votes








    7 Answers
    7






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    33














    If you use Disk Analyzer as a normal user there can be some files that you can't access or see. You can try to start it with superuser privileges. Open a terminal, or press ALT+F2 and type:



    gksudo baobab


    Baobab is the geeky name of the Disk Analyzer if you are wondering. Maybe it can now show you where those missing megabytes are.






    share|improve this answer





















    • 1





      Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

      – Yufenyuy Veyeh Dider
      Feb 6 '18 at 15:33
















    33














    If you use Disk Analyzer as a normal user there can be some files that you can't access or see. You can try to start it with superuser privileges. Open a terminal, or press ALT+F2 and type:



    gksudo baobab


    Baobab is the geeky name of the Disk Analyzer if you are wondering. Maybe it can now show you where those missing megabytes are.






    share|improve this answer





















    • 1





      Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

      – Yufenyuy Veyeh Dider
      Feb 6 '18 at 15:33














    33












    33








    33







    If you use Disk Analyzer as a normal user there can be some files that you can't access or see. You can try to start it with superuser privileges. Open a terminal, or press ALT+F2 and type:



    gksudo baobab


    Baobab is the geeky name of the Disk Analyzer if you are wondering. Maybe it can now show you where those missing megabytes are.






    share|improve this answer















    If you use Disk Analyzer as a normal user there can be some files that you can't access or see. You can try to start it with superuser privileges. Open a terminal, or press ALT+F2 and type:



    gksudo baobab


    Baobab is the geeky name of the Disk Analyzer if you are wondering. Maybe it can now show you where those missing megabytes are.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Feb 6 '18 at 16:28









    RoVo

    6,9781741




    6,9781741










    answered Dec 15 '10 at 11:02









    Javier RiveraJavier Rivera

    29.8k977101




    29.8k977101








    • 1





      Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

      – Yufenyuy Veyeh Dider
      Feb 6 '18 at 15:33














    • 1





      Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

      – Yufenyuy Veyeh Dider
      Feb 6 '18 at 15:33








    1




    1





    Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

    – Yufenyuy Veyeh Dider
    Feb 6 '18 at 15:33





    Also, remember that another shortcut to open your terminal in Ubuntu is Ctrl + Alt + T.

    – Yufenyuy Veyeh Dider
    Feb 6 '18 at 15:33













    17














    I solved it - thanks to all your advice, especially that of Javier Riveira, who suggested running Disk Analyzer with sudo rights (I didn't know this can have influence on the results).



    I have Crashplan, and it is making backups to some of the external drives. So there is a backup set which goes to Milly, and another one which goes to Sto_Lat, once every 15 minutes (these are the names of the external drives). When I have at some point started the computer without these drives, Crashplan has found no folders under /media/Milly and /media/Sto_Lat, so it has just created them and has written backups to them.



    For some reason, Disk Analyzer does not show these folders when started without sudo. Nautilus shows them, but lists the size of /media at 16 KB, when it is actually 30 GB.



    I only noticed this when I dismounted all external drives, including Milly and Sto_Lat, and started gksudo baobab. Then I saw my external drives where there should be none - but not all of them but only the backup targets - and realised that these are not mounted drives, but eponymous folders created by Crashplan. There must be something weird going on when I mount the drive at the same name as the existing folder, I wonder why I don't get an error message or something...



    BTW, this also solves why Disk Analyzer shows the sizes of Milly at 530 GB instead of 500 GB - these are the "missing" 30 GB, it counts the folder and the real drive together.



    Now I only need a way to delete the folders without breaking Crashplan or remaining without backups.






    share|improve this answer


























    • You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

      – Jorge Castro
      Dec 15 '10 at 21:17











    • This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

      – Michael Robinson
      Aug 31 '13 at 16:51











    • The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

      – arielf
      Sep 7 '15 at 1:36











    • @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

      – rumtscho
      Sep 7 '15 at 8:06











    • Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

      – arielf
      Sep 7 '15 at 21:23


















    17














    I solved it - thanks to all your advice, especially that of Javier Riveira, who suggested running Disk Analyzer with sudo rights (I didn't know this can have influence on the results).



    I have Crashplan, and it is making backups to some of the external drives. So there is a backup set which goes to Milly, and another one which goes to Sto_Lat, once every 15 minutes (these are the names of the external drives). When I have at some point started the computer without these drives, Crashplan has found no folders under /media/Milly and /media/Sto_Lat, so it has just created them and has written backups to them.



    For some reason, Disk Analyzer does not show these folders when started without sudo. Nautilus shows them, but lists the size of /media at 16 KB, when it is actually 30 GB.



    I only noticed this when I dismounted all external drives, including Milly and Sto_Lat, and started gksudo baobab. Then I saw my external drives where there should be none - but not all of them but only the backup targets - and realised that these are not mounted drives, but eponymous folders created by Crashplan. There must be something weird going on when I mount the drive at the same name as the existing folder, I wonder why I don't get an error message or something...



    BTW, this also solves why Disk Analyzer shows the sizes of Milly at 530 GB instead of 500 GB - these are the "missing" 30 GB, it counts the folder and the real drive together.



    Now I only need a way to delete the folders without breaking Crashplan or remaining without backups.






    share|improve this answer


























    • You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

      – Jorge Castro
      Dec 15 '10 at 21:17











    • This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

      – Michael Robinson
      Aug 31 '13 at 16:51











    • The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

      – arielf
      Sep 7 '15 at 1:36











    • @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

      – rumtscho
      Sep 7 '15 at 8:06











    • Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

      – arielf
      Sep 7 '15 at 21:23
















    17












    17








    17







    I solved it - thanks to all your advice, especially that of Javier Riveira, who suggested running Disk Analyzer with sudo rights (I didn't know this can have influence on the results).



    I have Crashplan, and it is making backups to some of the external drives. So there is a backup set which goes to Milly, and another one which goes to Sto_Lat, once every 15 minutes (these are the names of the external drives). When I have at some point started the computer without these drives, Crashplan has found no folders under /media/Milly and /media/Sto_Lat, so it has just created them and has written backups to them.



    For some reason, Disk Analyzer does not show these folders when started without sudo. Nautilus shows them, but lists the size of /media at 16 KB, when it is actually 30 GB.



    I only noticed this when I dismounted all external drives, including Milly and Sto_Lat, and started gksudo baobab. Then I saw my external drives where there should be none - but not all of them but only the backup targets - and realised that these are not mounted drives, but eponymous folders created by Crashplan. There must be something weird going on when I mount the drive at the same name as the existing folder, I wonder why I don't get an error message or something...



    BTW, this also solves why Disk Analyzer shows the sizes of Milly at 530 GB instead of 500 GB - these are the "missing" 30 GB, it counts the folder and the real drive together.



    Now I only need a way to delete the folders without breaking Crashplan or remaining without backups.






    share|improve this answer















    I solved it - thanks to all your advice, especially that of Javier Riveira, who suggested running Disk Analyzer with sudo rights (I didn't know this can have influence on the results).



    I have Crashplan, and it is making backups to some of the external drives. So there is a backup set which goes to Milly, and another one which goes to Sto_Lat, once every 15 minutes (these are the names of the external drives). When I have at some point started the computer without these drives, Crashplan has found no folders under /media/Milly and /media/Sto_Lat, so it has just created them and has written backups to them.



    For some reason, Disk Analyzer does not show these folders when started without sudo. Nautilus shows them, but lists the size of /media at 16 KB, when it is actually 30 GB.



    I only noticed this when I dismounted all external drives, including Milly and Sto_Lat, and started gksudo baobab. Then I saw my external drives where there should be none - but not all of them but only the backup targets - and realised that these are not mounted drives, but eponymous folders created by Crashplan. There must be something weird going on when I mount the drive at the same name as the existing folder, I wonder why I don't get an error message or something...



    BTW, this also solves why Disk Analyzer shows the sizes of Milly at 530 GB instead of 500 GB - these are the "missing" 30 GB, it counts the folder and the real drive together.



    Now I only need a way to delete the folders without breaking Crashplan or remaining without backups.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 13 '17 at 12:23









    Community

    1




    1










    answered Dec 15 '10 at 21:12









    rumtschorumtscho

    7012925




    7012925













    • You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

      – Jorge Castro
      Dec 15 '10 at 21:17











    • This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

      – Michael Robinson
      Aug 31 '13 at 16:51











    • The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

      – arielf
      Sep 7 '15 at 1:36











    • @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

      – rumtscho
      Sep 7 '15 at 8:06











    • Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

      – arielf
      Sep 7 '15 at 21:23





















    • You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

      – Jorge Castro
      Dec 15 '10 at 21:17











    • This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

      – Michael Robinson
      Aug 31 '13 at 16:51











    • The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

      – arielf
      Sep 7 '15 at 1:36











    • @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

      – rumtscho
      Sep 7 '15 at 8:06











    • Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

      – arielf
      Sep 7 '15 at 21:23



















    You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

    – Jorge Castro
    Dec 15 '10 at 21:17





    You should mark this as the accepted answer, I've added a link to Javier's answer so he can get upvotes for the tip.

    – Jorge Castro
    Dec 15 '10 at 21:17













    This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

    – Michael Robinson
    Aug 31 '13 at 16:51





    This is exactly the same problem I had. One of my backup disks had died but my backup script still attempted to backup to the /mnt/Backup-Drive folder, filling up my root disk.

    – Michael Robinson
    Aug 31 '13 at 16:51













    The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

    – arielf
    Sep 7 '15 at 1:36





    The reason you need sudo is that parts of the file system, are not readable to the user you're running as. This makes total sense, imagine if any user could read your full backups for example.

    – arielf
    Sep 7 '15 at 1:36













    @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

    – rumtscho
    Sep 7 '15 at 8:06





    @arielf I guess I had never given it much thought. But I sure expect a disk space counting utility to give me an accurate picture of the disk space used and free, maybe displaying a grey blob saying "this part is full, but you don't have the rights to see what's in there". I am quite surprised as a user when the files I have no right to read are counted towards free disk space.

    – rumtscho
    Sep 7 '15 at 8:06













    Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

    – arielf
    Sep 7 '15 at 21:23







    Well, you could simply run df which doesn't do a full directory scan and just gives the total vs free space of a partition. But if you want a full directory scan, with the detail given by baobab or filelight (at the individual file level), then full read permissions to the directories are needed.

    – arielf
    Sep 7 '15 at 21:23













    5














    You can use the Disk Usage Analyzer to scan your directories and see where your space is going on the filesystem.



    alt text



    As for not being able to see 30GB of your disk, open up GParted and see how the space is allocated on the disk. It may be that your partition scheme isn't what you thought it was.



    GParted






    share|improve this answer
























    • GParted was a good idea, but the mystery remains, see screenshot

      – rumtscho
      Dec 15 '10 at 1:01











    • That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

      – Nick Pascucci
      Dec 15 '10 at 3:25
















    5














    You can use the Disk Usage Analyzer to scan your directories and see where your space is going on the filesystem.



    alt text



    As for not being able to see 30GB of your disk, open up GParted and see how the space is allocated on the disk. It may be that your partition scheme isn't what you thought it was.



    GParted






    share|improve this answer
























    • GParted was a good idea, but the mystery remains, see screenshot

      – rumtscho
      Dec 15 '10 at 1:01











    • That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

      – Nick Pascucci
      Dec 15 '10 at 3:25














    5












    5








    5







    You can use the Disk Usage Analyzer to scan your directories and see where your space is going on the filesystem.



    alt text



    As for not being able to see 30GB of your disk, open up GParted and see how the space is allocated on the disk. It may be that your partition scheme isn't what you thought it was.



    GParted






    share|improve this answer













    You can use the Disk Usage Analyzer to scan your directories and see where your space is going on the filesystem.



    alt text



    As for not being able to see 30GB of your disk, open up GParted and see how the space is allocated on the disk. It may be that your partition scheme isn't what you thought it was.



    GParted







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Dec 14 '10 at 23:35









    Nick PascucciNick Pascucci

    1,7521314




    1,7521314













    • GParted was a good idea, but the mystery remains, see screenshot

      – rumtscho
      Dec 15 '10 at 1:01











    • That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

      – Nick Pascucci
      Dec 15 '10 at 3:25



















    • GParted was a good idea, but the mystery remains, see screenshot

      – rumtscho
      Dec 15 '10 at 1:01











    • That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

      – Nick Pascucci
      Dec 15 '10 at 3:25

















    GParted was a good idea, but the mystery remains, see screenshot

    – rumtscho
    Dec 15 '10 at 1:01





    GParted was a good idea, but the mystery remains, see screenshot

    – rumtscho
    Dec 15 '10 at 1:01













    That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

    – Nick Pascucci
    Dec 15 '10 at 3:25





    That is very strange indeed. Does the disk usage analyzer show any large files in the root dir?

    – Nick Pascucci
    Dec 15 '10 at 3:25











    4














    You can use du to show this:



    cd /
    sudo du -hcsx .[!.]* * | sort -rh | head


    or



    sudo du -hcsx * | sort -rh | head


    This will show what is using the most space.






    share|improve this answer






























      4














      You can use du to show this:



      cd /
      sudo du -hcsx .[!.]* * | sort -rh | head


      or



      sudo du -hcsx * | sort -rh | head


      This will show what is using the most space.






      share|improve this answer




























        4












        4








        4







        You can use du to show this:



        cd /
        sudo du -hcsx .[!.]* * | sort -rh | head


        or



        sudo du -hcsx * | sort -rh | head


        This will show what is using the most space.






        share|improve this answer















        You can use du to show this:



        cd /
        sudo du -hcsx .[!.]* * | sort -rh | head


        or



        sudo du -hcsx * | sort -rh | head


        This will show what is using the most space.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 23 '18 at 20:41

























        answered Mar 1 '16 at 0:16









        mchidmchid

        22.7k25184




        22.7k25184























            3














            As default there are 10% of your disk space reserved for the root user. You can change that using sudo tune2fs -m %percentage %device. In your case that would be sudo tune2fs -m 1 /dev/cciss/c0d0p1 for reducing the reservation to 1%. You can set it to any other number you like but I would not recommend 0%.






            share|improve this answer
























            • Is the 'sudo du -chs /' results anything to worry about?

              – dannymcc
              Oct 8 '12 at 9:25











            • I don't know but if you don't have any other problems I wouldn't mind ;-)

              – André Stannek
              Oct 8 '12 at 9:28
















            3














            As default there are 10% of your disk space reserved for the root user. You can change that using sudo tune2fs -m %percentage %device. In your case that would be sudo tune2fs -m 1 /dev/cciss/c0d0p1 for reducing the reservation to 1%. You can set it to any other number you like but I would not recommend 0%.






            share|improve this answer
























            • Is the 'sudo du -chs /' results anything to worry about?

              – dannymcc
              Oct 8 '12 at 9:25











            • I don't know but if you don't have any other problems I wouldn't mind ;-)

              – André Stannek
              Oct 8 '12 at 9:28














            3












            3








            3







            As default there are 10% of your disk space reserved for the root user. You can change that using sudo tune2fs -m %percentage %device. In your case that would be sudo tune2fs -m 1 /dev/cciss/c0d0p1 for reducing the reservation to 1%. You can set it to any other number you like but I would not recommend 0%.






            share|improve this answer













            As default there are 10% of your disk space reserved for the root user. You can change that using sudo tune2fs -m %percentage %device. In your case that would be sudo tune2fs -m 1 /dev/cciss/c0d0p1 for reducing the reservation to 1%. You can set it to any other number you like but I would not recommend 0%.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Oct 8 '12 at 9:21









            André StannekAndré Stannek

            3,3411736




            3,3411736













            • Is the 'sudo du -chs /' results anything to worry about?

              – dannymcc
              Oct 8 '12 at 9:25











            • I don't know but if you don't have any other problems I wouldn't mind ;-)

              – André Stannek
              Oct 8 '12 at 9:28



















            • Is the 'sudo du -chs /' results anything to worry about?

              – dannymcc
              Oct 8 '12 at 9:25











            • I don't know but if you don't have any other problems I wouldn't mind ;-)

              – André Stannek
              Oct 8 '12 at 9:28

















            Is the 'sudo du -chs /' results anything to worry about?

            – dannymcc
            Oct 8 '12 at 9:25





            Is the 'sudo du -chs /' results anything to worry about?

            – dannymcc
            Oct 8 '12 at 9:25













            I don't know but if you don't have any other problems I wouldn't mind ;-)

            – André Stannek
            Oct 8 '12 at 9:28





            I don't know but if you don't have any other problems I wouldn't mind ;-)

            – André Stannek
            Oct 8 '12 at 9:28











            1














            Do the following at let me know how it went:




            1. Insert a LiveCd and fsck your /dev/sda1

            2. Clean your Trash Can.

            3. See the Log File Viewer for weird stuff that is happening.

            4. Test (If you can) with a normal HDD (Not SSD). Just to remove that option.


            Let me know how it went.






            share|improve this answer
























            • Posted the info you requested, see edit in the question.

              – rumtscho
              Dec 15 '10 at 1:01
















            1














            Do the following at let me know how it went:




            1. Insert a LiveCd and fsck your /dev/sda1

            2. Clean your Trash Can.

            3. See the Log File Viewer for weird stuff that is happening.

            4. Test (If you can) with a normal HDD (Not SSD). Just to remove that option.


            Let me know how it went.






            share|improve this answer
























            • Posted the info you requested, see edit in the question.

              – rumtscho
              Dec 15 '10 at 1:01














            1












            1








            1







            Do the following at let me know how it went:




            1. Insert a LiveCd and fsck your /dev/sda1

            2. Clean your Trash Can.

            3. See the Log File Viewer for weird stuff that is happening.

            4. Test (If you can) with a normal HDD (Not SSD). Just to remove that option.


            Let me know how it went.






            share|improve this answer













            Do the following at let me know how it went:




            1. Insert a LiveCd and fsck your /dev/sda1

            2. Clean your Trash Can.

            3. See the Log File Viewer for weird stuff that is happening.

            4. Test (If you can) with a normal HDD (Not SSD). Just to remove that option.


            Let me know how it went.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 14 '10 at 23:07









            Luis AlvaradoLuis Alvarado

            144k135484649




            144k135484649













            • Posted the info you requested, see edit in the question.

              – rumtscho
              Dec 15 '10 at 1:01



















            • Posted the info you requested, see edit in the question.

              – rumtscho
              Dec 15 '10 at 1:01

















            Posted the info you requested, see edit in the question.

            – rumtscho
            Dec 15 '10 at 1:01





            Posted the info you requested, see edit in the question.

            – rumtscho
            Dec 15 '10 at 1:01











            1














            I really don't know if this helps you, but in my case I also experienced that, my HDD was loosing free space over time without a reason. It turned out that the default settings in synaptic package manager was also a contributor to that. The default settings in the preferences, under the file tab will instruct synaptic to keep all downloaded packages in the cache. Over the time that can accumulate a nice mountain of files.
            I changed the settings to delete downloaded packages after installation. That helped to recover quite a nice amount of free space.



            Again I'm really not sure if that helps in your case, but you might check the synaptic cache, maybe that's full with files that are obsolete.






            share|improve this answer



















            • 1





              interesting to know, but this cache would be counted as part of the filesystem.

              – rumtscho
              Dec 15 '10 at 20:55
















            1














            I really don't know if this helps you, but in my case I also experienced that, my HDD was loosing free space over time without a reason. It turned out that the default settings in synaptic package manager was also a contributor to that. The default settings in the preferences, under the file tab will instruct synaptic to keep all downloaded packages in the cache. Over the time that can accumulate a nice mountain of files.
            I changed the settings to delete downloaded packages after installation. That helped to recover quite a nice amount of free space.



            Again I'm really not sure if that helps in your case, but you might check the synaptic cache, maybe that's full with files that are obsolete.






            share|improve this answer



















            • 1





              interesting to know, but this cache would be counted as part of the filesystem.

              – rumtscho
              Dec 15 '10 at 20:55














            1












            1








            1







            I really don't know if this helps you, but in my case I also experienced that, my HDD was loosing free space over time without a reason. It turned out that the default settings in synaptic package manager was also a contributor to that. The default settings in the preferences, under the file tab will instruct synaptic to keep all downloaded packages in the cache. Over the time that can accumulate a nice mountain of files.
            I changed the settings to delete downloaded packages after installation. That helped to recover quite a nice amount of free space.



            Again I'm really not sure if that helps in your case, but you might check the synaptic cache, maybe that's full with files that are obsolete.






            share|improve this answer













            I really don't know if this helps you, but in my case I also experienced that, my HDD was loosing free space over time without a reason. It turned out that the default settings in synaptic package manager was also a contributor to that. The default settings in the preferences, under the file tab will instruct synaptic to keep all downloaded packages in the cache. Over the time that can accumulate a nice mountain of files.
            I changed the settings to delete downloaded packages after installation. That helped to recover quite a nice amount of free space.



            Again I'm really not sure if that helps in your case, but you might check the synaptic cache, maybe that's full with files that are obsolete.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Dec 15 '10 at 10:33









            AndyBAndyB

            33927




            33927








            • 1





              interesting to know, but this cache would be counted as part of the filesystem.

              – rumtscho
              Dec 15 '10 at 20:55














            • 1





              interesting to know, but this cache would be counted as part of the filesystem.

              – rumtscho
              Dec 15 '10 at 20:55








            1




            1





            interesting to know, but this cache would be counted as part of the filesystem.

            – rumtscho
            Dec 15 '10 at 20:55





            interesting to know, but this cache would be counted as part of the filesystem.

            – rumtscho
            Dec 15 '10 at 20:55


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Ask Ubuntu!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f17467%2fwhat-is-taking-up-so-much-space-on-my-disk-beside-the-filesystem%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Ellipse (mathématiques)

            Quarter-circle Tiles

            Mont Emei