headers
Sandon Van Ness | 1 Jun 2010 18:23

df reports wrong disk space usage on solaris

I installed OpenSSH_5.3p1 on my opensolaris file-server as the default
version didn't seem to support disk space usage at all (showed 1000G
with 0 used) and now it shows the correct percentage but it is giving me
out of wack values (in the Petabyte range):

root <at> sabayonx86-64: 09:21 AM :~# df -H
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sdc2               35G    32G   3.3G  91% /
udev                    13G   283k    13G   1% /dev
none                   2.1M   324k   1.8M  16% /lib/rcscripts/init.d
/dev/sdc1              100M    89M    12M  89% /boot
/dev/sda1               84G    60G    25G  71% /winxp
tmpfs                   13G      0    13G   0% /dev/shm
/dev/sdc3               18T    15T   3.6T  80% /data
box:/data              8.9T   7.9T   1.1T  89% /colo
osol:/data             4.5P   3.2P   1.3P  72% /osol

This is not the correct size of the volume as it should be 18TB with df -H:

root <at> opensolaris: 09:24 AM :~# df -H /data
Filesystem             Size   Used  Avail Use% Mounted on
data                    18T    13T   5.1T  72% /data

The percentage it lists; however, is ok. Also when mounting the near
same size file-sytem on a linux host to another linux machine I see the
correct values:

hptc ~ # df -H /sshfs
Filesystem             Size   Used  Avail Use% Mounted on
1.1.1.3:/data           18T    15T   3.6T  80% /sshfs
(Continue reading)

Permalink | Reply | 24 comments |
headers
Miklos Szeredi | 1 Jun 2010 22:22
Picon

Re: df reports wrong disk space usage on solaris

On Tue, 01 Jun 2010, Sandon Van Ness wrote:
> I installed OpenSSH_5.3p1 on my opensolaris file-server as the default
> version didn't seem to support disk space usage at all (showed 1000G
> with 0 used) and now it shows the correct percentage but it is giving me
> out of wack values (in the Petabyte range):
> 
> root <at> sabayonx86-64: 09:21 AM :~# df -H
> Filesystem             Size   Used  Avail Use% Mounted on
> /dev/sdc2               35G    32G   3.3G  91% /
> udev                    13G   283k    13G   1% /dev
> none                   2.1M   324k   1.8M  16% /lib/rcscripts/init.d
> /dev/sdc1              100M    89M    12M  89% /boot
> /dev/sda1               84G    60G    25G  71% /winxp
> tmpfs                   13G      0    13G   0% /dev/shm
> /dev/sdc3               18T    15T   3.6T  80% /data
> box:/data              8.9T   7.9T   1.1T  89% /colo
> osol:/data             4.5P   3.2P   1.3P  72% /osol

I believe the problem is that "df" uses statfs, not statvfs.  If
f_frsize and f_bsize differ then df will give the wrong answer, as
statfs doesn't have an f_frsize field.

Try "stat -f /osol" to verify this theory.

> 
> This is not the correct size of the volume as it should be 18TB with df -H:
> 
> root <at> opensolaris: 09:24 AM :~# df -H /data
> Filesystem             Size   Used  Avail Use% Mounted on
> data                    18T    13T   5.1T  72% /data
(Continue reading)

Permalink | Reply | 23 comments |
headers
Sandon Van Ness | 1 Jun 2010 22:38

Re: df reports wrong disk space usage on solaris

On 06/01/2010 01:22 PM, Miklos Szeredi wrote:
> On Tue, 01 Jun 2010, Sandon Van Ness wrote:
>   
>> I installed OpenSSH_5.3p1 on my opensolaris file-server as the default
>> version didn't seem to support disk space usage at all (showed 1000G
>> with 0 used) and now it shows the correct percentage but it is giving me
>> out of wack values (in the Petabyte range):
>>
>> root <at> sabayonx86-64: 09:21 AM :~# df -H
>> Filesystem             Size   Used  Avail Use% Mounted on
>> /dev/sdc2               35G    32G   3.3G  91% /
>> udev                    13G   283k    13G   1% /dev
>> none                   2.1M   324k   1.8M  16% /lib/rcscripts/init.d
>> /dev/sdc1              100M    89M    12M  89% /boot
>> /dev/sda1               84G    60G    25G  71% /winxp
>> tmpfs                   13G      0    13G   0% /dev/shm
>> /dev/sdc3               18T    15T   3.6T  80% /data
>> box:/data              8.9T   7.9T   1.1T  89% /colo
>> osol:/data             4.5P   3.2P   1.3P  72% /osol
>>     
> I believe the problem is that "df" uses statfs, not statvfs.  If
> f_frsize and f_bsize differ then df will give the wrong answer, as
> statfs doesn't have an f_frsize field.
>
> Try "stat -f /osol" to verify this theory.
>
> Yep, linux sets f_frsize and f_bsize to the same values (presumably
> not to break df).
>
> Thanks,
(Continue reading)

Permalink | Reply | 22 comments |
headers
Sandon Van Ness | 2 Jun 2010 03:37

Re: df reports wrong disk space usage on solaris

On 06/01/2010 01:38 PM, Sandon Van Ness wrote:
> On 06/01/2010 01:22 PM, Miklos Szeredi wrote:
>   
>> On Tue, 01 Jun 2010, Sandon Van Ness wrote:
>>   
>>     
>>> I installed OpenSSH_5.3p1 on my opensolaris file-server as the default
>>> version didn't seem to support disk space usage at all (showed 1000G
>>> with 0 used) and now it shows the correct percentage but it is giving me
>>> out of wack values (in the Petabyte range):
>>>
>>> root <at> sabayonx86-64: 09:21 AM :~# df -H
>>> Filesystem             Size   Used  Avail Use% Mounted on
>>> /dev/sdc2               35G    32G   3.3G  91% /
>>> udev                    13G   283k    13G   1% /dev
>>> none                   2.1M   324k   1.8M  16% /lib/rcscripts/init.d
>>> /dev/sdc1              100M    89M    12M  89% /boot
>>> /dev/sda1               84G    60G    25G  71% /winxp
>>> tmpfs                   13G      0    13G   0% /dev/shm
>>> /dev/sdc3               18T    15T   3.6T  80% /data
>>> box:/data              8.9T   7.9T   1.1T  89% /colo
>>> osol:/data             4.5P   3.2P   1.3P  72% /osol
>>>     
>>>       
>> I believe the problem is that "df" uses statfs, not statvfs.  If
>> f_frsize and f_bsize differ then df will give the wrong answer, as
>> statfs doesn't have an f_frsize field.
>>
>> Try "stat -f /osol" to verify this theory.
>>
(Continue reading)

Permalink | Reply | 21 comments |
headers
Miklos Szeredi | 2 Jun 2010 12:40
Picon

Re: df reports wrong disk space usage on solaris

[bug-coreutils <at> ... added to CC]

On Tue, 01 Jun 2010, Sandon Van Ness wrote:
> > NFS:
> >
> > root <at> sabayonx86-64: 01:27 PM :~# stat -f /osol
> >   File: "/osol"
> >     ID: 0        Namelen: 255     Type: nfs
> > Block size: 32768      Fundamental block size: 32768
> > Blocks: Total: 532021184  Free: 109079823  Available: 109079823
> > Inodes: Total: 6987112837 Free: 6981108616
> >
> > SSHFS:
> > root <at> sabayonx86-64: 01:27 PM :~# stat -f /sshfs
> >   File: "/sshfs"
> >     ID: 0        Namelen: 255     Type: UNKNOWN (0x65735546)
> > Block size: 131072     Fundamental block size: 131072
> > Blocks: Total: 34049356570 Free: 6980647748 Available: 6980647748
> > Inodes: Total: 6986651970 Free: 6980647748
> >   
> Also here is the stats on the solaris box itself vs ssshfs:
> 
> opensolaris:
> 
> 
> root <at> opensolaris: 06:38 PM :/usr/local/etc#  stat -f /data
>   File: "/data"
>     ID: 1690006  Namelen: 255     Type: zfs
> Block size: 131072     Fundamental block size: 512
> Blocks: Total: 34049348764 Free: 6056839257 Available: 6056839257
(Continue reading)

Permalink | Reply | 20 comments |
headers
Miklos Szeredi | 3 Jun 2010 10:40
Picon

Re: bug#6331: df reports wrong disk space usage on solaris

On Thu, 03 Jun 2010, Jim Meyering wrote:
> Miklos Szeredi wrote:
> ...
> > Notice that the real statfs syscall does have an f_frsize field, but
> > for some historical reason it is not exported in the library API.
> >
> > Options to fix this behavior would be:
> >
> >  1) fix df and stat in coreutils to use statvfs
> >  2) make sshfs set f_bsize to f_frsize
> >  3) make sshfs set f_frsize to f_bsize and recalculate stats
> >  4) change both f_frsize and f_bsize to a common value and
> >     recalculate stats (this is what NFS appears to be doing)
> >
> > There is some difficulty with 1) as the libc implementation of statvfs
> > has problems:
> >
> >  "Do not use statvfs on systems with GNU libc on Linux, because that function
> >   stats all preceding entries in /proc/mounts, and that makes df hang if even
> >   one of the corresponding file systems is hard-mounted, but not available.
> >   statvfs in GNU libc on Hurd, BeOS, Haiku operates differently: it only makes
> >   a system call."
> >
> > This might have been fixed in libc since, so it's possible that
> > coreutils developers are willing to using statvfs on linux.
> 
> glibc's statvfs still appears to have this problem, so coreutils' df
> must not use that function.  To demonstrate, I recompiled fsusage.c
> with -DSTAT_STATVFS, relinked df, and ran this:
>
(Continue reading)

Permalink | Reply | 17 comments |
headers
Harald Judt | 9 Jun 2010 15:45
Picon
Picon

Bug: Cannot access or delete files starting with .#

Hi,

When emacs opens a file, it also creates a symlink indicating that the
file is being edited. This symlink usually has the following scheme:
.#originalfilename -> user <at> hostname.domain.somenumber:somenumber

This file cannot be accessed using sshfs. Therefore, it will not be
deleted automatically by emacs, and you have to connect to the server
via ssh and delete it there.

e.g.:
  rm: cannot remove `.#test.php': No such file or directory
  and ls -la shows this:
  ?????????? ? ?     ?         ?             ? .#test.php

Best regards,
Harald

--

-- 
`Experience is the best teacher.'

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
Permalink | Reply | 6 comments |
headers
Miklos Szeredi | 9 Jun 2010 15:52
Picon

Re: Bug: Cannot access or delete files starting with .#

On Wed, 09 Jun 2010, Harald Judt wrote:
> Hi,
> 
> When emacs opens a file, it also creates a symlink indicating that the
> file is being edited. This symlink usually has the following scheme:
> .#originalfilename -> user <at> hostname.domain.somenumber:somenumber
> 
> This file cannot be accessed using sshfs. Therefore, it will not be
> deleted automatically by emacs, and you have to connect to the server
> via ssh and delete it there.
> 
> e.g.:
>   rm: cannot remove `.#test.php': No such file or directory
>   and ls -la shows this:
>   ?????????? ? ?     ?         ?             ? .#test.php

I cannot reproduce this.  Editing files with emacs over sshfs works
perfectly for me, the .#filename symlink isn't left behind after the
file is saved.

What is the ssh version on the server end?

Thanks,
Miklos

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
(Continue reading)

Permalink | Reply | 5 comments |
headers
Harald Judt | 9 Jun 2010 16:21
Picon
Picon

Re: Bug: Cannot access or delete files starting with .#

Hi,

At Wed, 09 Jun 2010 15:52:39 +0200,
Miklos Szeredi <miklos <at> szeredi.hu> wrote:
> 
> On Wed, 09 Jun 2010, Harald Judt wrote:
> > Hi,
> > 
> > When emacs opens a file, it also creates a symlink indicating that the
> > file is being edited. This symlink usually has the following scheme:
> > .#originalfilename -> user <at> hostname.domain.somenumber:somenumber
> > 
> > This file cannot be accessed using sshfs. Therefore, it will not be
> > deleted automatically by emacs, and you have to connect to the server
> > via ssh and delete it there.
> > 
> > e.g.:
> >   rm: cannot remove `.#test.php': No such file or directory
> >   and ls -la shows this:
> >   ?????????? ? ?     ?         ?             ? .#test.php
> 
> I cannot reproduce this.  Editing files with emacs over sshfs works
> perfectly for me, the .#filename symlink isn't left behind after the
> file is saved.
> 
> What is the ssh version on the server end?

The problem only occurs when using the follow_symlinks option, if I
don't use it these symlinks get deleted properly. Maybe sshfs can
handle such cases? SSH version on the server doesn't seem to matter.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Miklos Szeredi | 9 Jun 2010 16:32
Picon

Re: Bug: Cannot access or delete files starting with .#

On Wed, 09 Jun 2010, Harald Judt wrote:
> Hi,
> 
> At Wed, 09 Jun 2010 15:52:39 +0200,
> Miklos Szeredi <miklos <at> szeredi.hu> wrote:
> > 
> > On Wed, 09 Jun 2010, Harald Judt wrote:
> > > Hi,
> > > 
> > > When emacs opens a file, it also creates a symlink indicating that the
> > > file is being edited. This symlink usually has the following scheme:
> > > .#originalfilename -> user <at> hostname.domain.somenumber:somenumber
> > > 
> > > This file cannot be accessed using sshfs. Therefore, it will not be
> > > deleted automatically by emacs, and you have to connect to the server
> > > via ssh and delete it there.
> > > 
> > > e.g.:
> > >   rm: cannot remove `.#test.php': No such file or directory
> > >   and ls -la shows this:
> > >   ?????????? ? ?     ?         ?             ? .#test.php
> > 
> > I cannot reproduce this.  Editing files with emacs over sshfs works
> > perfectly for me, the .#filename symlink isn't left behind after the
> > file is saved.
> > 
> > What is the ssh version on the server end?
> 
> The problem only occurs when using the follow_symlinks option, if I
> don't use it these symlinks get deleted properly. Maybe sshfs can
(Continue reading)

Permalink | Reply | 3 comments |

Gmane