Missing space on my hard drive, 100% used and deleting files gives back no space.
This is with Suse 9.1 on a Reiser filesystem. Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back. I did not have the forsight to put /tmp on a separate disk partition, so my entire root directory is affected. Luckily my /home is on it's own partition, but has not filled up, so I am able to get some work done. Anything that wants to open a temporary file just crashes. I have some other partitions, mainly used for holding mp3s and alike that have the same problem. All of these partitions, /, /home, and /data[1-4] are on the same physical hard drive. The partitions with this problem show up un Konqueror's 'Properties' tab as being 100% used as well as showing 65.8MB free. This is with 10GB partitions. It seems odd to me that they should all show 65.8MB free. I did run reiserfsck but it didn't report anything unusual, but there could well be command line switches to utilise that I do not know about. Has this been heard of elsewhere and is there a simple cure? -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Friday 12 November 2004 21:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Note that files that are held open by programs won't be deleted until the programs end, or otherwise close the files
The partitions with this problem show up un Konqueror's 'Properties' tab as being 100% used as well as showing 65.8MB free. This is with 10GB partitions. It seems odd to me that they should all show 65.8MB free.
What is the output of "fdisk -l" "cat /proc/mounts" and "df" ?
I did run reiserfsck but it didn't report anything unusual
Does that mean the partition was unmounted? And it still didn't give you space back when you deleted files? Try emptying /tmp out completely, there shouldn't be anything there worth saving when a system is shut down anyway, there should only be temporary files
On Fri November 12 2004 2:18 pm, Anders Johansson wrote:
On Friday 12 November 2004 21:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Note that files that are held open by programs won't be deleted until the programs end, or otherwise close the files
The partitions with this problem show up un Konqueror's 'Properties' tab as being 100% used as well as showing 65.8MB free. This is with 10GB partitions. It seems odd to me that they should all show 65.8MB free.
What is the output of "fdisk -l" "cat /proc/mounts" and "df" ?
Note that you can also use 'lsof' to detect files that are deleted but still held open. In this case, something like "lsof +D /tmp" should help. -Nick -- <<< The Matrix is everywhere. >>> /`-_ Nicholas R. LeRoy The Condor Project { }/ http://www.cs.wisc.edu/~nleroy http://www.cs.wisc.edu/condor \ / nleroy@cs.wisc.edu The University of Wisconsin |_*_| 608-265-5761 Department of Computer Sciences
On Friday 12 November 2004 20:18, Anders Johansson wrote:
What is the output of "fdisk -l" "cat /proc/mounts" and "df" ?
linux:/home/colin # fdisk -l Disk /dev/hda: 61.4 GB, 61492838400 bytes 255 heads, 63 sectors/track, 7476 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 201 1614501 82 Linux swap /dev/hda2 202 1507 10490445 83 Linux /dev/hda3 1508 2813 10490445 83 Linux /dev/hda4 * 2814 7476 37455547+ f W95 Ext'd (LBA) /dev/hda5 2814 4119 10490413+ 83 Linux /dev/hda6 4120 5425 10490413+ 83 Linux /dev/hda7 5426 6731 10490413+ 83 Linux /dev/hda8 6732 7476 5984181 83 Linux linux:/home/colin # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / reiserfs rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 /dev/hda3 /home reiserfs rw 0 0 /dev/dvdrecorder /media/dvdrecorder subfs ro,nosuid,nodev 0 0 /dev/fd0 /media/floppy subfs rw,sync,nosuid,nodev 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 usbfs /proc/bus/usb usbfs rw 0 0 linux:/home/colin # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 10396296 93808 100% / tmpfs 258244 24 258220 1% /dev/shm /dev/hda3 10490104 984044 9506060 10% /home
I did run reiserfsck but it didn't report anything unusual
Does that mean the partition was unmounted? And it still didn't give you space back when you deleted files? Try emptying /tmp out completely, there shouldn't be anything there worth saving when a system is shut down anyway, there should only be temporary files
I ran it in single user mode, so I think the root partition was unmounted. Right or wrong? linux:/tmp # du 0 ./.ICE-unix 0 ./kde-colin 0 ./ksocket-colin 0 ./.X11-unix 0 ./.font-unix 4 . linux:/tmp # From the command line what command can I run to give a list of file in /, listed in size order, starting with the largest? From a GUI point of view I use KDirStat, which doesn't show up anything unusual and lost. I don't think I can rely on the GUI at the moment though. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
Colin Murphy wrote:
From the command line what command can I run to give a list of file in /, listed in size order, starting with the largest? From a GUI point of view I use KDirStat, which doesn't show up anything unusual and lost. I don't think I can rely on the GUI at the moment though.
du -k --max-depth=1 / | sort -n It will take some time to finish the scan (10 GB at / + a 1 GB at /home to search), because sort will wait du to finish its output to actually display it sorted. Don't use the -h switch, or sort will get confused. If you have enough RAM, subsequents commands in inner directories will be much faster. -- Marcos
On Friday 12 November 2004 21:47, Colin Murphy wrote:
I ran it in single user mode, so I think the root partition was unmounted. Right or wrong?
No, it was mounted, but there shouldn't be any significant processes running in runlevel 1 holding files, so that I think can be ruled out
linux:/tmp # du 0 ./.ICE-unix 0 ./kde-colin 0 ./ksocket-colin 0 ./.X11-unix 0 ./.font-unix 4 . linux:/tmp #
OK, so your problem isn't in /tmp
From the command line what command can I run to give a list of file in /, listed in size order, starting with the largest?
Hm, one way would be find / -type f -xdev -exec du -s {} \; |sort -g but that would take forever. A better way would be to log in as root, unmount /home, and run "du -s /*". That will tell you which directory takes up an inordinate amount of space. Say it's /usr for example, then you'd do "du -s /usr/*" and continue drilling down until you've found the culprit
I don't know if this has been covered, but a technique that both
legitimate and not-so-legitimate software sometimes use is this:
open a file "foo"
unlink file "foo"
Now, you have a file *handle* to a file that doesn't exist (has no
name), but *does* have control of it's inode, and you can allocate space
all day long with it. Other programs can't *list* it, can't *see* it,
and without intimate knowledge of the filesystem, can't *access* it in
any meaningful way.
All of the allocated space for the file gets deallocated when the /last/
file handle to it is closed.
--
Carpe diem - Seize the day.
Carp in denim - There's a fish in my pants!
Jon Nelson
On Friday 12 November 2004 22:26, Jon Nelson wrote:
Other programs can't *list* it, can't *see* it, and without intimate knowledge of the filesystem, can't *access* it in any meaningful way.
All files opened are hard linked from /proc/<pid>/fd/ and can be accessed through that link (permissions permitting, naturally). The general rule is that an inode (and the data it points to) is marked as available when the last hard link goes away, and that hard link in /proc is what keeps deleted files hanging around. It's a good thing to know if you accidentally delete a file and you still have it open in a program. Just cp that hard link and you've "undeleted" it
Anders,
Just how is you know so much!!!
I've been working with UNIX for 20 years and linux for 7 or 8, and I'm
still amazed at all the little trivia things you know.
Greg
On Fri, 12 Nov 2004 22:35:51 +0100, Anders Johansson
On Friday 12 November 2004 22:26, Jon Nelson wrote:
Other programs can't *list* it, can't *see* it, and without intimate knowledge of the filesystem, can't *access* it in any meaningful way.
All files opened are hard linked from /proc/<pid>/fd/ and can be accessed through that link (permissions permitting, naturally). The general rule is that an inode (and the data it points to) is marked as available when the last hard link goes away, and that hard link in /proc is what keeps deleted files hanging around. It's a good thing to know if you accidentally delete a file and you still have it open in a program. Just cp that hard link and you've "undeleted" it
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Friday 12 November 2004 22:39, Greg Freemyer wrote:
Anders,
Just how is you know so much!!!
It would have been more impressive if I had been right, wouldn't it. It seems that either things have changed or my memory is going prematurely. I'll have to check up on this
On Friday 12 November 2004 22:48, Anders Johansson wrote:
On Friday 12 November 2004 22:39, Greg Freemyer wrote:
Anders,
Just how is you know so much!!!
It would have been more impressive if I had been right, wouldn't it. It seems that either things have changed or my memory is going prematurely. I'll have to check up on this
OK, I was right on the first try. I was confused momentarily when I tried to verify my statement by opening a file in vim and I then didn't see the link in the fd directory. I thought things had changed in 2.6, but it hasn't, the link is there, it's just that vim doesn't keep the file open while you edit it, it just works on the .swp file; I didn't know that, so that threw me
Anders Johansson wrote:
On Friday 12 November 2004 21:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Note that files that are held open by programs won't be deleted until the programs end, or otherwise close the files
I suppose one solution, would be to run a script at bootup, that deletes files that haven't been accessed in a while.
On Saturday 13 November 2004 19:14, James Knott wrote:
Anders Johansson wrote:
On Friday 12 November 2004 21:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Note that files that are held open by programs won't be deleted until the programs end, or otherwise close the files
I suppose one solution, would be to run a script at bootup, that deletes files that haven't been accessed in a while.
I don't know if you want to just delete everything, but perhaps a mail to root (or some other admin user) alerting him to the old (or unusually large, or whatever criteria) files might be an idea. But I'm not sure it's a complete solution. First it's a very common optimisation to mount partitions with the 'noatime' flag, to speed up disk accesses, in which case you can't tell when a file was last accessed. And secondly, if there is a process running amok filling up disk space, then the file(s) it creates will have been accessed very recently, perhaps even most recently, so your script would look at every file except the ones actually causing the problem. It is a good idea though to clean up old and unused junk. So setting CLEAN_TMP_DIRS_AT_BOOTUP to "yes" would be a good idea (if your applications store anything in /tmp that they expect to survive a reboot there's something wrong with them anyway), and you probably want to keep a close eye on the directories in /var, especially if you build a lot of rpms (the default temporary install root is in /var/tmp), and there could be runaway log files in /var/log, and it's a very good idea to use quotas on those file systems. If you then run your servers with different users, one server can never cause other servers from running out of space
On Saturday 13 November 2004 19:46, James Knott wrote:
Anders Johansson wrote:
It is a good idea though to clean up old and unused junk. So setting CLEAN_TMP_DIRS_AT_BOOTUP to "yes" would be a good idea
Where's that option found?
Oh, sorry, it's in /etc/sysconfig/cron
Op zaterdag 13 november 2004 19:51, schreef Anders Johansson:
On Saturday 13 November 2004 19:46, James Knott wrote:
Anders Johansson wrote:
It is a good idea though to clean up old and unused junk. So setting CLEAN_TMP_DIRS_AT_BOOTUP to "yes" would be a good idea
Where's that option found?
Oh, sorry, it's in /etc/sysconfig/cron
yast -> system -> misc -> editor for sysconfig files. than: system -> cron In 9.2 you find there an additional option, one for short and long (period wise) tmp directories. That means that /tmp (short e.g. 3 days) and /var/tmp (long e.g. 14 days) can be cleaned with this option indepent from each other ;) -- Richard
On Friday 12 November 2004 15:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Make sure you don't have a rogue process running that is filling up disk space as fast as you empty it.
I did run reiserfsck but it didn't report anything unusual, but there could well be command line switches to utilise that I do not know about.
If you can run it, kdirstat gives a nice graphical representation of the filesystem. You can see at a glance which files and directories are using up the disk space. I actually had your problem this morning and in 3 minutes found out that the .xsession-errors file in my home directory had grown to 5.6GB. Jeff
Colin Murphy wrote:
Has this been heard of elsewhere and is there a simple cure?
Overflowing tmp and var is common. What you can do, is boot with a rescue disk or installation CD. Then move the /tmp directory to a partition with lots of space and then create a symlink to it. Still though, it's a good idea to occasionally clean the garbage out of /tmp.
Op zaterdag 13 november 2004 19:04, schreef James Knott:
Overflowing tmp and var is common. What you can do, is boot with a rescue disk or installation CD. Then move the /tmp directory to a partition with lots of space and then create a symlink to it. Still though, it's a good idea to occasionally clean the garbage out of /tmp.
Or use LVM so you can grow the partitions when needed ;) -- Richard Bos Without a home the journey is endless
On Friday 12 November 2004 20:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Thanks to all who have posted so far on this subject. I am still scratching my head though. I have been able to delete files from the /tmp directory and get SOME free space back but I still don't think the figures add up. I can't be exactly sure with /tmp because I've lost count and it is on the same filesystem as my root directories, so I went to something more basic. I said that some of the other filesystems were showing the same problem, one of them being my /data1 directory where I keep Stuff(tm). This is on its own 10GB Reiser partition and also got filled to capacity, according to Konqueror at least, where the Properties tab currently shows "Free disk space: 2.8 GB out of 10.0GB (72% used)" even though there are no files there according to Konqueror and confirmed with colin@linux:/data1> du /data1 0 /data1 When I started posting on this subject /data1 did have files in it and was reported, by Konqueror, as being "100% full with 65MB free" (sic). I copied all of the files from /data1 to elsewhere and found there were only 2.1GB of files anyway. Anyone any clues as to what is causing this? How do I find out about free space on a partition from the command line? I fear that relying on Konqueror may be adding an extra level of complication. I just want to look at /data1 so I thought colin@linux:/data1> df /data1 would do the trick but it still gives me details of the root partition:- Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7526516 2963588 72% / Thanks again for your time. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Friday 12 November 2004 20:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Thanks to all who have posted so far on this subject. I am still scratching my head though. I have been able to delete files from the /tmp directory and get SOME free space back but I still don't think the figures add up. I can't be exactly sure with /tmp because I've lost count and it is on the same filesystem as my root directories, so I went to something more basic. I said that some of the other filesystems were showing the same problem, one of them being my /data1 directory where I keep Stuff(tm). This is on its own 10GB Reiser partition and also got filled to capacity, according to Konqueror at least, where the Properties tab currently shows "Free disk space: 2.8 GB out of 10.0GB (72% used)" even though there are no files there according to Konqueror and confirmed with colin@linux:/data1> du /data1 0 /data1 When I started posting on this subject /data1 did have files in it and was reported, by Konqueror, as being "100% full with 65MB free" (sic). I copied all of the files from /data1 to elsewhere and found there were only 2.1GB of files anyway. Anyone any clues as to what is causing this? How do I find out about free space on a partition from the command line? I fear that relying on Konqueror may be adding an extra level of complication. I just want to look at /data1 so I thought colin@linux:/data1> df /data1 would do the trick but it still gives me details of the root partition:- Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7526516 2963588 72% / Thanks again for your time. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Sunday 14 November 2004 10:05, Colin Murphy sent a duplicate message: Sorry for that. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
Colin Murphy wrote:
On Friday 12 November 2004 20:00, Colin Murphy wrote:
This is with Suse 9.1 on a Reiser filesystem.
Unfortunately I allowed my /tmp directory to fill up and even though I am deleting files I don't seem to be getting any space back.
Thanks to all who have posted so far on this subject. I am still scratching my head though.
I have been able to delete files from the /tmp directory and get SOME free space back but I still don't think the figures add up. I can't be exactly sure with /tmp because I've lost count and it is on the same filesystem as my root directories, so I went to something more basic.
I said that some of the other filesystems were showing the same problem, one of them being my /data1 directory where I keep Stuff(tm). This is on its own 10GB Reiser partition and also got filled to capacity, according to Konqueror at least, where the Properties tab currently shows "Free disk space: 2.8 GB out of 10.0GB (72% used)" even though there are no files there according to Konqueror and confirmed with
colin@linux:/data1> du /data1 0 /data1
If this is said before then sorry. Just jumped in. You may wane try this on the command line: du -h --max-depth=1 This will give de disk usage in MB and GB. and only for the directories from where you started it.
When I started posting on this subject /data1 did have files in it and was reported, by Konqueror, as being "100% full with 65MB free" (sic). I copied all of the files from /data1 to elsewhere and found there were only 2.1GB of files anyway.
Anyone any clues as to what is causing this?
How do I find out about free space on a partition from the command line? I fear that relying on Konqueror may be adding an extra level of complication. I just want to look at /data1 so I thought
colin@linux:/data1> df /data1
This works only for mounted filesystems. So was data1 mounted??
would do the trick but it still gives me details of the root partition:-
Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7526516 2963588 72% /
Thanks again for your time.
Hope this Helps, Stefan.
On Sunday 14 November 2004 12:05, S. Bulterman wrote:
This works only for mounted filesystems. So was data1 mounted??
Yes, I think so. With things like automount it is sometimes hard to be certain, so I went and did:- colin@linux:/data1> touch /data1/emptytestfile colin@linux:/data1> ls emptytestfile colin@linux:/data1> du -h --max-depth=1 0 . colin@linux:/data1> df /data1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7525288 2964816 72% / colin@linux:/data1> For the record Konqueror now shows the file but still shows that something else has taken 7.2GB of the space in this partition.
Hope this Helps,
Directly, no. But it's the helpfull thoughts that keep me going ;-) -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
Colin, On Sunday 14 November 2004 05:10, Colin Murphy wrote:
On Sunday 14 November 2004 12:05, S. Bulterman wrote:
This works only for mounted filesystems. So was data1 mounted??
Yes, I think so. With things like automount it is sometimes hard to be certain, so I went and did:-
colin@linux:/data1> touch /data1/emptytestfile colin@linux:/data1> ls emptytestfile colin@linux:/data1> du -h --max-depth=1 0 . colin@linux:/data1> df /data1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7525288 2964816 72% / colin@linux:/data1>
For the record Konqueror now shows the file but still shows that something else has taken 7.2GB of the space in this partition.
No, I don't think it does. That "df" output means that nothing is mounted on "/data1". Df accepts files and directories as arguments and then reports on the file system that holds those files or directories. The output it's producing for you implies there's nothing mounted on /data1. You can see what's mounted by using the "mount" command or by viewing "/proc/mounts". Naturally, coming directly from the kernel, /proc/mounts is not subject to any potential discrepancy as the contents of "/etc/mtab" can be. If you haven't already, read the man pages on "du" and "find" (it has options to find files using their size or size range as a criterion) to help you resolve this problem. If you end up with a very large list (say of directories and their space occupancy from du), use "sort -rn" to find the largest ones. And if the list you need to sort doesn't have the sizes first, read about sort's key field selection options. You may find the "-S" / "--separate-dirs" option to du helpful; it keeps du from adding the contents of subdirectories into the size it reports for directories higher up in the file system. Good luck.
-- Colin@SpudULike.me.uk As seasons go I especially like pepper.
That's "seasonings"... Randall Schulz
On Sunday 14 November 2004 16:19, Randall R Schulz wrote:
No, I don't think it does.
[...] In fact this is the 'private' message I speak of elsewhere. Obviously sent to the list and myself directly. I didn't appreciate the list was so slow in passing on messages so assumed it was sent to me alone. Thanks again Randall. -- Colin@SpudULike.me.uk A man for all seasons, especially pepper.
On Sunday 14 November 2004 13:10, Colin Murphy wrote:
On Sunday 14 November 2004 12:05, S. Bulterman wrote:
This works only for mounted filesystems. So was data1 mounted??
Yes, I think so. With things like automount it is sometimes hard to be certain, so I went and did:-
colin@linux:/data1> touch /data1/emptytestfile colin@linux:/data1> ls emptytestfile colin@linux:/data1> du -h --max-depth=1 0 . colin@linux:/data1> df /data1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda2 10490104 7525288 2964816 72% / colin@linux:/data1>
For the record Konqueror now shows the file but still shows that something else has taken 7.2GB of the space in this partition.
A private email on this subject made me question if /data1 was, in fact, mounted, in the normal sense. Yes, I had just written to the directory and read it back, but when I went to look at mount, /data1 was not listed. Mounting this by hand revealed a clutch of missing directories that make up the difference in space. Obviously there's a gap in my knowledge about how partitions get mounted in Suse 9.1, can anyone out there point me in the right direction to fill it? Konqueror and, from memory commands like ls, failed to show up these missing directories, showing only some. None I could understand, but why only some? -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Sunday 14 November 2004 11:17 am, Colin Murphy wrote:
On Sunday 14 November 2004 13:10, Colin Murphy wrote:
On Sunday 14 November 2004 12:05, S. Bulterman wrote:
This works only for mounted filesystems. So was data1 mounted??
A private email on this subject made me question if /data1 was, in fact, mounted, in the normal sense. Yes, I had just written to the directory and read it back, but when I went to look at mount, /data1 was not listed. Mounting this by hand revealed a clutch of missing directories that make up the difference in space.
Obviously there's a gap in my knowledge about how partitions get mounted in Suse 9.1, can anyone out there point me in the right direction to fill it?
Konqueror and, from memory commands like ls, failed to show up these missing directories, showing only some. None I could understand, but why only some? Hi,
I, for one, would really like to know the final conclusions on this prob. Be sure to post what you find out, please. PeterB
On Saturday 13 November 2004 17:57, Peter B Van Campen wrote:
I, for one, would really like to know the final conclusions on this prob. Be sure to post what you find out, please.
A curious collection of problems I've amassed. It would appear that I have a partition that I can read and write to even if it is not mounted:- linux:/home/colin # cat /etc/fstab /dev/hda2 / reiserfs acl,user_xattr 1 1 /dev/hda5 /data1 auto noauto,user 0 0 [...] /dev/hda3 /home reiserfs acl,user_xattr 1 2 /dev/hda1 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 linux:/home/colin # /data1 has it's own partition. This is how the partition appears after I've started the system up:- linux:/home/colin # ls -l /data1 total 1 drwxr-xrwx 2 root root 80 2004-11-14 12:57 . drwxr-xr-x 25 root root 584 2004-11-10 20:54 .. -rw-r--r-- 1 colin users 0 2004-11-14 12:57 emptytestfile linux:/home/colin # I can even view this file in Konqueror. linux:/home/colin # mount /data1 linux:/home/colin # ls -l /data1 total 3 drwxrwxr-x 12 root users 312 2004-08-30 09:24 . drwxr-xr-x 25 root root 584 2004-11-10 20:54 .. drwxr-xr-x 3 colin users 104 2004-08-30 09:12 Benzai Republic [...] drwxr-xr-x 3 colin users 80 2004-08-30 09:06 The Feelers drwxr-xr-x 4 colin users 128 2004-08-30 08:45 Viviam Stanshall linux:/home/colin # Note, emptytestfile does not appear in this 'mounted version' ??? But if I : linux:/home/colin # umount /data1 The unmounted version comes back. I can even write to the file, note the file size: linux:/ # ls -l /data1 total 5 drwxr-xrwx 2 root root 80 2004-11-14 21:24 . drwxr-xr-x 25 root root 584 2004-11-10 20:54 .. -rw-r--r-- 1 colin users 38 2004-11-14 21:24 emptytestfile linux:/ # Can someone explain how this can be please? -- Colin@SpudULike.me.uk A man for all seasons, especially pepper.
On Sunday 14 November 2004 22:40, Colin Murphy wrote:
A curious collection of problems I've amassed. It would appear that I have a partition that I can read and write to even if it is not mounted:-
Can someone explain how this can be please?
OK, let me try When a linux system starts up, you have one partition mounted, the so-called "root" partition. in this partition, you have a number of directories, one of them is called /data1. If you don't do anything else, and you create a file in /data1, that file will be created on the root partition just as it would in any other directory Now, if you "mount" another partition on /data1, what you're saying to the system is "everytime the user wants to do something in /data1, it should happen on this other partition". So after "mount /dev/hda5 /data1", if you do "ls /data1" the system will show you the contents of the hda5 partition. The file you created before you mounted the hda5 partition will still be there on the root partition, it's just that the system hides it while hda5 is mounted. /data1 isn't special just because it's a "mount point", it's just a regular directory. You can use any directory as a mount point for other partitions. (trying to think of some descriptive analogy, it's hard, how about this:) Think of /data1 as a magician's trick door. Behind the door is a regular room, but when you throw a switch, the door suddenly leads out to the garden. The original room, along with what you put in it, is still there, but while the switch is on (the partition is mounted) whenever you go through the door you will get to the garden Yeah, ok, lame analogy, but it's the best I could do on short notice :)
On Sunday 14 November 2004 23:06, Anders Johansson wrote:
On Sunday 14 November 2004 22:40, Colin Murphy wrote:
A curious collection of problems I've amassed. It would appear that I have a partition that I can read and write to even if it is not mounted:-
Can someone explain how this can be please?
OK, let me try
When a linux system starts up, you have one partition mounted, the so-called "root" partition. in this partition, you have a number of directories, one of them is called /data1. If you don't do anything else, and you create a file in /data1, that file will be created on the root partition just as it would in any other directory
Now, if you "mount" another partition on /data1, what you're saying to the system is "everytime the user wants to do something in /data1, it should happen on this other partition". So after "mount /dev/hda5 /data1", if you do "ls /data1" the system will show you the contents of the hda5 partition. The file you created before you mounted the hda5 partition will still be there on the root partition, it's just that the system hides it while hda5 is mounted.
/data1 isn't special just because it's a "mount point", it's just a regular directory. You can use any directory as a mount point for other partitions.
(trying to think of some descriptive analogy, it's hard, how about this:) Think of /data1 as a magician's trick door. Behind the door is a regular room, but when you throw a switch, the door suddenly leads out to the garden. The original room, along with what you put in it, is still there, but while the switch is on (the partition is mounted) whenever you go through the door you will get to the garden
Yeah, ok, lame analogy, but it's the best I could do on short notice :)
No, not lame. Not at all. It is just another way of describing what happens here: $ mkdir /data1 $ echo "This is the first test" >> /data1/testfile.txt $ cat /data1/testfile.txt This is the first test $ mount /dev/hda17 /data1 $ echo "This is the second test" >> /data1/testfile.txt $ cat /data1/testfile.txt This is the second test $ umount /data1 $ cat /data1/testfile.txt This is the first test Cheers, Leen
On Sunday 14 November 2004 05:06 pm, Anders Johansson wrote:
/data1 isn't special just because it's a "mount point", it's just a regular directory. You can use any directory as a mount point for other partitions.
(trying to think of some descriptive analogy, it's hard, how about this:) Think of /data1 as a magician's trick door. Behind the door is a regular room, but when you throw a switch, the door suddenly leads out to the garden. The original room, along with what you put in it, is still there, but while the switch is on (the partition is mounted) whenever you go through the door you will get to the garden
Yeah, ok, lame analogy, but it's the best I could do on short notice :)
Your patience amazes me..... but is very welcome in this forum..... :-)
On Sunday 14 November 2004 22:06, Anders Johansson wrote:
Yeah, ok, lame analogy,
No, not lame and I thank you for it. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Sunday 14 November 2004 2:06 pm, Anders Johansson wrote:
OK, let me try
Yeah, ok, lame analogy, but it's the best I could do on short notice :)
Great explanation, very clear and simple to understand! Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.111-default x86_64
Anders Johansson wrote:
On Sunday 14 November 2004 22:40, Colin Murphy wrote:
A curious collection of problems I've amassed. It would appear that I have a partition that I can read and write to even if it is not mounted:-
I got rid of automount long ago. All the disks are in fstab. ["Now I'm here, now I'm there"-snip] (c.right Queen)
(trying to think of some descriptive analogy, it's hard, how about this:) Think of /data1 as a magician's trick door. Behind the door is a regular room, but when you throw a switch, the door suddenly leads out to the garden. The original room, along with what you put in it, is still there, but while the switch is on (the partition is mounted) whenever you go through the door you will get to the garden
Yeah, ok, lame analogy, but it's the best I could do on short notice :)
Disney's Monsters & Co. ? ;-) Ciao, Ermanno
On Sunday 14 November 2004 4:40 pm, Colin Murphy wrote:
On Saturday 13 November 2004 17:57, Peter B Van Campen wrote:
I, for one, would really like to know the final conclusions on this prob. Be sure to post what you find out, please.
A curious collection of problems I've amassed. It would appear that I have a partition that I can read and write to even if it is not mounted:-
linux:/home/colin # cat /etc/fstab
I suggest running the "mount" command to see what's mounted. I've also occasionally had two mounts for the same filesystem (I think), which can produce odd behavior. Paul
On Sunday 14 November 2004 22:13, Paul W. Abrahams wrote:
I suggest running the "mount" command to see what's mounted. I've also occasionally had two mounts for the same filesystem (I think), which can produce odd behavior.
Indeed, it was mount that alerted me to this issue earlier on in the thread. The behaviour is very odd. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
Op zondag 14 november 2004 22:40, schreef Colin Murphy:
The unmounted version comes back. I can even write to the file, note the file size: linux:/ # ls -l /data1 total 5 drwxr-xrwx 2 root root 80 2004-11-14 21:24 . drwxr-xr-x 25 root root 584 2004-11-10 20:54 .. -rw-r--r-- 1 colin users 38 2004-11-14 21:24 emptytestfile linux:/ #
Can someone explain how this can be please?
/data1 is a mountpoint located most likely on the partition "/". It means that it is just a part of "/" and as such can be written. Now if one mounts another partition on the mountpount, the information that is stored under the mountpoint gets hidden by the newly mounted partition. Nothing magic, I would say. It is a nice way to get "/" full...., when you expect a big sized partition to be mounted on /data1 and it is not there. If you now write lots of data to /data1, it is written to the partition holding "/", which is most often not so big... -- Richard Bos Without a home the journey is endless
On Sunday 14 November 2004 22:23, Richard Bos wrote:
It is a nice way to get "/" full...., when you expect a big sized partition to be mounted on /data1 and it is not there. If you now write lots of data to /data1, it is written to the partition holding "/", which is most often not so big...
Which would tie up nicely with why /tmp did run out of space, it being a branch off / . -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
Richard Bos wrote:
Op zondag 14 november 2004 22:40, schreef Colin Murphy:
The unmounted version comes back. I can even write to the file, note the file size:
<snip>
It is a nice way to get "/" full...., when you expect a big sized partition to be mounted on /data1 and it is not there. If you now write lots of data to /data1, it is written to the partition holding "/", which is most often not so big...
This certainly is not his problem. If it were, there would be a lot more in that directory than just his little testfile. Only one person that I recall has mentioned /var, and then no more has been said about it that I can recall. As I said to Colin in private email... du -sh /var --max-depth=1 and then we can see just how much of that drive is full of things like logs.
On Sunday 14 November 2004 21:40, Colin Murphy wrote:
On Saturday 13 November 2004 17:57, Peter B Van Campen wrote:
I, for one, would really like to know the final conclusions on this prob. Be sure to post what you find out, please.
For Peter and anyone else then this is what appears to have happened. For some reason a usually mounted filesystem, that usually lives on its own partition, /dev/hda5, was not mounted under its usual directory name /data1. Why this might be will have to wait for another thread. Even though the usual partition had not been mounted, data was still being saved under the directory /data1, which at this time was just a normal directory on the partition that hold / as well as /tmp and /var. Lots of space was expected to be available in /data1 because it was expected to be mounted to a nice big partition. Now, when lots of data was being saved to /data1 it was going to the wrong partition, which was smaller and, more importantly, needed for other things, like keeping the system running. I suppose, at some point, /data1 would have appeared empty, it not being mounted onto the right partition. This would have been the first, possibly only time that I could have realised that a problem was looming and that something was not being mounted correctly. Thanks to all that helped me find the problem. -- Colin@SpudULike.me.uk As seasons go I especially like pepper.
On Monday 15 November 2004 00:58, Colin Murphy wrote:
For some reason a usually mounted filesystem, that usually lives on its own partition, /dev/hda5, was not mounted under its usual directory name /data1. Why this might be will have to wait for another thread.
No it won't :) It's because you have 'noauto' on the line in /etc/fstab, that means it shouldn't be mounted automatically when you boot.
participants (18)
-
Anders Johansson -
Bruce Marshall -
Colin Murphy -
Darryl Gregorash -
Ermanno Polli -
Greg Freemyer -
James Knott -
Jeffrey Laramie -
Jon Nelson -
Leendert Meyer -
Marcos Lazarini -
Nick LeRoy -
Paul W. Abrahams -
Peter B Van Campen -
Randall R Schulz -
Richard Bos -
S. Bulterman -
Scott Leighton