FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 01-18-2008, 07:53 AM
Neil Bird
 
Default df not reporting correct free space - hard link problems?

On my (ext3, LVM) drive on which I perform backups, I went to copy a
large directory and starting getting loads of out-of-space errors, even
though 'df' reports plenty of room, even to non-root users.



$ df -h /usr/backup
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sata0-backup
464G 367G 88G 81% /usr/backup

.. but:

mv: cannot create regular file `blah': No space left on device


Now, I am using rsync to create daily+weekly backups on that drive, so
there are wads of hard links to things several times over. But 'df' should
be able to cope with that, shouldn't it?


I ran a forced fsck on the drive, but that reported no problems. Any
ideas anyone?


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-18-2008, 08:32 AM
Tony Molloy
 
Default df not reporting correct free space - hard link problems?

On Friday 18 January 2008 08:53:53 Neil Bird wrote:
> On my (ext3, LVM) drive on which I perform backups, I went to copy a
> large directory and starting getting loads of out-of-space errors, even
> though 'df' reports plenty of room, even to non-root users.
>
>
> $ df -h /usr/backup
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/sata0-backup
> 464G 367G 88G 81% /usr/backup
>
> .. but:
>
> mv: cannot create regular file `blah': No space left on device
>
>
> Now, I am using rsync to create daily+weekly backups on that drive, so
> there are wads of hard links to things several times over. But 'df' should
> be able to cope with that, shouldn't it?
>
> I ran a forced fsck on the drive, but that reported no problems. Any
> ideas anyone?

Could be you're out of inodes on the filesystem. Try


/usr/lib/news/bin/inndf -i /usr/backup

This should give you a count of free inodes.

Tony
>
> --
> [neil@fnx ~]# rm -f .signature
> [neil@fnx ~]# ls -l .signature
> ls: .signature: No such file or directory
> [neil@fnx ~]# exit


--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-18-2008, 12:38 PM
Les Mikesell
 
Default df not reporting correct free space - hard link problems?

Neil Bird wrote:


On my (ext3, LVM) drive on which I perform backups, I went to copy a
large directory and starting getting loads of out-of-space errors, even
though 'df' reports plenty of room, even to non-root users.



$ df -h /usr/backup
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sata0-backup
464G 367G 88G 81% /usr/backup

.. but:

mv: cannot create regular file `blah': No space left on device


If you have a lot of small files you might run out of inodes before
using all the space. Try 'df -i'.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-18-2008, 06:28 PM
Martin Marques
 
Default df not reporting correct free space - hard link problems?

Tony Molloy escribió:

On Friday 18 January 2008 08:53:53 Neil Bird wrote:

On my (ext3, LVM) drive on which I perform backups, I went to copy a
large directory and starting getting loads of out-of-space errors, even
though 'df' reports plenty of room, even to non-root users.


$ df -h /usr/backup
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sata0-backup
464G 367G 88G 81% /usr/backup

.. but:

mv: cannot create regular file `blah': No space left on device


Now, I am using rsync to create daily+weekly backups on that drive, so
there are wads of hard links to things several times over. But 'df' should
be able to cope with that, shouldn't it?

I ran a forced fsck on the drive, but that reported no problems. Any
ideas anyone?


Could be you're out of inodes on the filesystem. Try


/usr/lib/news/bin/inndf -i /usr/backup

This should give you a count of free inodes.


What's inndf? I don't have it on my system.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-19-2008, 08:14 PM
Cameron Simpson
 
Default df not reporting correct free space - hard link problems?

On 18Jan2008 08:53, Neil Bird <neil@fnxweb.com> wrote:
> On my (ext3, LVM) drive on which I perform backups, I went to copy a
> large directory and starting getting loads of out-of-space errors,

Using what precise copy command?

> even
> though 'df' reports plenty of room, even to non-root users.
> $ df -h /usr/backup
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/sata0-backup
> 464G 367G 88G 81% /usr/backup
> .. but:
> mv: cannot create regular file `blah': No space left on device

"mv" is not a copy command. And I don't think it prserves hard links.

> Now, I am using rsync to create daily+weekly backups on that drive, so
> there are wads of hard links to things several times over. But 'df' should
> be able to cope with that, shouldn't it?

Df copes just fine. But mv-ing a tree with lots of hard links to another
filesystem almost certainly makes separate copies of each link, at vast disc
space expense. It also doesn't cope with sparse files, though you probably
don't have any.

> I ran a forced fsck on the drive, but that reported no problems. Any
> ideas anyone?

Hard links in source. No hard links in destination. "ls -i" can show
this, example:

ls -ldi /src/file1 /src/file2
ls -ldi /dst/file1 /dst/file2

Presuming file1 and file2 were hard links in /src/, they will have the
same inode number. If they are two different inode numbers in /dst/ then
they are two copies, consuming twice the space. There's a link count
column in "ls -l", too, which will show this effect.

You're using the wrong copy command. Try this:

mkdir /path/to/target
rsync -aH /path/to/source/ /path/to/target/

Note the "H" option - it is vital.

In short, df _is_ reporting correct free space. You're using space up
faster that you imagined.
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

We had the experience, but missed the meaning. - T.S. Eliot

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-21-2008, 09:21 AM
Neil Bird
 
Default df not reporting correct free space - hard link problems?

Around about 19/01/08 21:14, Cameron Simpson typed ...

Using what precise copy command?
In short, df _is_ reporting correct free space. You're using space up
faster that you imagined.


I was actually using 'cp -ax' which sorts out hard links properly. The
mv example was for, erm, an example. Thanks, but it was the inodes thing
after all.


--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-21-2008, 09:31 AM
Neil Bird
 
Default df not reporting correct free space - hard link problems?

Around about 18/01/08 09:32, Tony Molloy typed ...

Could be you're out of inodes on the filesystem. Try
/usr/lib/news/bin/inndf -i /usr/backup


Around about 18/01/08 13:38, Les Mikesell typed ...
> If you have a lot of small files you might run out of inodes before
> using all the space. Try 'df -i'.


That was, in fact, the problem:

$ df -i /usr/backup/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/sata0-backup
474624 471797 2827 100% /usr/backup


That Inodes number's extremely low in comparison to my other partitions.
Is it low because of the partition size (which would be off) or because I
(think I) created the partition with the 'largefiles' option (it's mostly
got mythtv recording backups on it; yes, I like my TV ).


I assume I can't do anything about it now it's in use (i.e., no runtime
changing of the inodes count). Even if I did regenerate the filesystem,
does anyone know if it's 'safe' to override the inode count with mke2fs's '-N'?


I've worked around the issue for now by deleting and now backing up
superfluous dierctoies with wads of files in (~/.thumbnails ~/.beagle) so
I'm back a decent no. of free inodes.


Thanks for the help.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 
Old 01-21-2008, 10:51 AM
Ian Malone
 
Default df not reporting correct free space - hard link problems?

Neil Bird wrote:

Around about 18/01/08 09:32, Tony Molloy typed ...

Could be you're out of inodes on the filesystem. Try
/usr/lib/news/bin/inndf -i /usr/backup


Around about 18/01/08 13:38, Les Mikesell typed ...
> If you have a lot of small files you might run out of inodes before
> using all the space. Try 'df -i'.


That was, in fact, the problem:

$ df -i /usr/backup/
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/sata0-backup
474624 471797 2827 100% /usr/backup


That Inodes number's extremely low in comparison to my other
partitions. Is it low because of the partition size (which would be
off) or because I (think I) created the partition with the 'largefiles'
option (it's mostly got mythtv recording backups on it; yes, I like my
TV ).




In comparison my / is 28GB, is nearly full and is only using 8% of 7M
inodes (FC6 plus home directory, filled with source trees, video and
email). Largefile has a seriously low inode ratio: see /etc/mke2fs.

I assume I can't do anything about it now it's in use (i.e., no
runtime changing of the inodes count). Even if I did regenerate the
filesystem, does anyone know if it's 'safe' to override the inode count
with mke2fs's '-N'?




The standard setup will give you lots more inodes. So far as safe goes
the only danger I know of is the one you have run into (or
over-specifying inodes and have no data space). I'd guess the default
should be fine, but you might want to work out what your current ratio
of inodes to space is. As far as I know you're right; you can't change
the inode count in-situ.

--
imalone

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
 

Thread Tools




All times are GMT. The time now is 09:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org