David Wright wrote:
> On Tue 18 Jun 2024 at 19:29:31 (-0400), songbird wrote:
>
>> "df -x tmpfs" does the magic and gives me the better view that is
>> more useful.
>
> FWIW I define dfree as:
>
> df --output=source,ipcent,fstype,size,used,avail,pcent,targ
On Tue 18 Jun 2024 at 19:29:31 (-0400), songbird wrote:
> "df -x tmpfs" does the magic and gives me the better view that is
> more useful.
FWIW I define dfree as:
df --output=source,ipcent,fstype,size,used,avail,pcent,target -B 100 -x
tmpfs -x devtmpfs -x fuse.po
recent bloat of tmpfs /run/{blah}
looks horrible whenever i check the status of my file systems.
it would be much better if those all went under just one tmpfs.
luckily there is an option for that so i'll alias df with that
option included. :)
=
Filesystem Size Used
On Wed 11 Mar 2020 at 11:13:30 (-0400), rhkra...@gmail.com wrote:
> On Wednesday, March 11, 2020 10:41:19 AM David Wright wrote:
> > Well, I'm glad that's all sorted. Now all I've got to figure out is
> > the connection between df and whoami.
>
> Pretty mu
On Wed 11 Mar 2020 at 10:43:46 (-0400), Greg Wooledge wrote:
> On Wed, Mar 11, 2020 at 09:41:19AM -0500, David Wright wrote:
> > $ whoami
> > david
>
> > $ df -h --all | grep -e 'Filesystem ' -e $(whoami)
> > Filesystem Size Used Avail Use% Mou
On Wednesday, March 11, 2020 10:41:19 AM David Wright wrote:
> Well, I'm glad that's all sorted. Now all I've got to figure out is
> the connection between df and whoami.
Pretty much, there is no relation.
Maybe you're wondering about why some directories or files (
On Wed, Mar 11, 2020 at 09:41:19AM -0500, David Wright wrote:
> $ whoami
> david
> $ df -h --all | grep -e 'Filesystem ' -e $(whoami)
> Filesystem Size Used Avail Use% Mounted on
> $
What did you *expect*? There are no lines containing "david" in
df's output.
t; > > with your help I found a way around it (here is my silly scripting):
> > > >
> > > > $ sudo _DF=$(df -h)
> > >
> > > I don't think you need "sudo" for "df"?
> >
> > And a good thing, too, because that synta
gt; > >
> > > $ sudo _DF=$(df -h)
> >
> > I don't think you need "sudo" for "df"?
>
> And a good thing, too, because that syntax is completely wrong.
>
> wooledg:~$ sudo x=$(id)
> usage: sudo -h | -K | -k | -V
[...]
> I think
On Wed, Mar 11, 2020 at 01:21:17PM +0100, to...@tuxteam.de wrote:
> On Wed, Mar 11, 2020 at 01:02:59PM +0100, Albretch Mueller wrote:
> > with your help I found a way around it (here is my silly scripting):
> >
> > $ sudo _DF=$(df -h)
>
> I don't think you n
On Wed, Mar 11, 2020 at 01:02:59PM +0100, Albretch Mueller wrote:
> with your help I found a way around it (here is my silly scripting):
>
> $ sudo _DF=$(df -h)
I don't think you need "sudo" for "df"?
Cheers
-- tomás
signature.asc
Description: Digital signature
with your help I found a way around it (here is my silly scripting):
$ sudo _DF=$(df -h)
date
echo "${_DF}" | head -n 1
echo "${_DF}" | grep $(whoami)
$
lbrtchx
> /dev/sda1: UUID="22e7b834-11f9-4f29-84d2-8757aa9f721d" TYPE="ext2"
> PARTUUID="c67530bc-01"
> /dev/sda5: UUID="27928fd6-a5a9-47a7-8e84-c65c2e2ed1df"
> TYPE="crypto_LUKS" PARTUUID="c67530bc-05"
> /dev/mappe
9a2"
> TYPE="ext4"
> /dev/sda1: UUID="22e7b834-11f9-4f29-84d2-8757aa9f721d" TYPE="ext2"
> PARTUUID="c67530bc-01"
> /dev/sda5: UUID="27928fd6-a5a9-47a7-8e84-c65c2e2ed1df" TYPE="crypto_LUKS"
> PARTUUID="c67530bc-05
TYPE="ext2"
PARTUUID="c67530bc-01"
/dev/sda5: UUID="27928fd6-a5a9-47a7-8e84-c65c2e2ed1df"
TYPE="crypto_LUKS" PARTUUID="c67530bc-05"
/dev/mapper/lbrtchx--vg-swap_1:
UUID="0e990461-59f0-470c-9e07-c2942e683d2a" TYPE="
On Mon, Jun 03, 2019 at 09:06:11PM -0700, Ross Boylan wrote:
>
> Takeaways:
> * Don't say 4TB when you mean 4GB! (Duh)
> * e2fs tools report (roughly?) the entire device size for block count,
> while df only shows the size of the data area, excluding metadata
> * Mis-size
Le 03/06/2019 à 19:36, Ross Boylan a écrit :
I just noticed the reported journal size is exactly 1G, which would
account for the difference:
Journal size: 1024M
That's assuming the units are bytes; if they are blocks, it's just a
crazy value.
Sounds interesting. Here on a ~4 GiB ext
nal 4TB size I specified. There are some additional
suboptimalities from shrinking by a factor of 1000, but the log size
is the only substantial one. To reset the journal size he recommended
removing and then recreating the journal, which worked for me. df now
reports 4G as the volume size, with a corresp
I just noticed the reported journal size is exactly 1G, which would
account for the difference:
Journal size: 1024M
That's assuming the units are bytes; if they are blocks, it's just a
crazy value.
I'll see what the extN experts have to say.
Ross
# ls -l /dev/mapper/vgbarley-cache /dev/vgbarley/cache
lrwxrwxrwx 1 root root 8 Jun 1 17:26 /dev/mapper/vgbarley-cache -> ../dm-19
lrwxrwxrwx 1 root root 8 Jun 1 17:26 /dev/vgbarley/cache -> ../dm-19
On Mon, Jun 3, 2019 at 2:32 AM Henning Follmann
wrote:
>
> You cheat ;)
> please show that
>
>
On Sat, Jun 01, 2019 at 02:46:00PM -0700, Ross Boylan wrote:
> # df -B4096 /var/local/cache/
> Filesystem 4K-blocks Used Available Use% Mounted on
> /dev/mapper/vgbarley-cache778160 191713529923 27% /var/local/cache
>
> # e2fsck -v /dev/vgbarley/cache
> If the filesystem and the volume manager both agree on 4GB, I don't
> know where df is getting the notion that it's 3GB. It seems very
Sure looks like a bug. I think reporting it as a bug to the ext234
people is The Right Thing to do.
Stefan
nd it still reports 1M blocks @4k/block -> 4G
Although the blocks in use are very high, 469k -> 1.6G (48%)
In contrast, df reports 770M/3G in use (28%). So if there's 1G that
is somehow hidden from that total, adding it to both sides gives
roughly
1.8G/4G which is close to the 1.6G repor
don't
think the partitioning of the raw disks is directly relevant.
The analogue to the partition size is the logical volume size. As my
original message showed, LVM does think the volume is 4GB.
If the filesystem and the volume manager both agree on 4GB, I don't
know where df is getting
I suggest trying gparted to read the partition table on your drive.
There may be a problem and gparted is usually pretty good at finding
partition table errors.
On 2019-06-01 1:41 p.m., Ross Boylan wrote:
df says my volume is 3G, but everything else says it's 4G. What's
going on a
Le 01/06/2019 à 23:46, Ross Boylan a écrit :
# e2fsck -v /dev/vgbarley/cache
e2fsck 1.44.5 (15-Dec-2018)
/dev/vgbarley/cache: clean, 8361/131072 files, 462129/1048576 blocks
You must specify -f for a complete check.
# df -B4096 /var/local/cache/
Filesystem 4K-blocks Used Available Use% Mounted on
/dev/mapper/vgbarley-cache778160 191713529923 27% /var/local/cache
# e2fsck -v /dev/vgbarley/cache
e2fsck 1.44.5 (15-Dec-2018)
/dev/vgbarley/cache: clean, 8361/131072 files, 462129/1048576
Le 01/06/2019 à 19:41, Ross Boylan a écrit :
df says my volume is 3G, but everything else says it's 4G. What's
going on and how can I correct it?
Did you try e2fsck ?
On Sat, Jun 01, 2019 at 10:41:20AM -0700, Ross Boylan wrote:
> df says my volume is 3G, but everything else says it's 4G. What's
> going on and how can I correct it?
>
> This question concerns the total reported space, not the free space.
>
> The volume is an LVM l
df says my volume is 3G, but everything else says it's 4G. What's
going on and how can I correct it?
This question concerns the total reported space, not the free space.
The volume is an LVM logical volume on buster with an ext4 file
system. I originally mistakenly created it as 4
On Sun, Aug 26, 2018 at 12:25:44PM +1000, Zenaan Harkness wrote:
df shows bytes, df -h shows only one decimal place, so e.g. on a
1.8TiB drive "1.6T" is the free space, but that resolution/ precision
is insufficient.
Insufficient for what?
On 26-08-2018, at 01h 08'57", Roberto C. Sánchez wrote about "Re: df -h shows
insufficient precision"
> > > Have you looked at the -k and -B options? Also, di has the -d option
> >
> > I assume you mean "du"?
> >
> No. I actually m
On 26.08.18 12:25, Zenaan Harkness wrote:
> A regular itchy annoyance for years now:
>
> df shows bytes, df -h shows only one decimal place, so e.g. on a
> 1.8TiB drive "1.6T" is the free space, but that resolution/ precision
> is insufficient.
For more than 3 decades I
On Sun, Aug 26, 2018 at 03:04:38PM +1000, Zenaan Harkness wrote:
> On Sat, Aug 25, 2018 at 10:38:19PM -0400, Roberto C. Sánchez wrote:
> > On Sun, Aug 26, 2018 at 12:25:44PM +1000, Zenaan Harkness wrote:
> > > A regular itchy annoyance for years now:
> > >
> > &
On Sat, Aug 25, 2018 at 10:38:19PM -0400, Roberto C. Sánchez wrote:
> On Sun, Aug 26, 2018 at 12:25:44PM +1000, Zenaan Harkness wrote:
> > A regular itchy annoyance for years now:
> >
> > df shows bytes, df -h shows only one decimal place, so e.g. on a
> > 1.8TiB dri
On Sun, Aug 26, 2018 at 12:25:44PM +1000, Zenaan Harkness wrote:
> A regular itchy annoyance for years now:
>
> df shows bytes, df -h shows only one decimal place, so e.g. on a
> 1.8TiB drive "1.6T" is the free space, but that resolution/ precision
> is insufficient. O
A regular itchy annoyance for years now:
df shows bytes, df -h shows only one decimal place, so e.g. on a
1.8TiB drive "1.6T" is the free space, but that resolution/ precision
is insufficient. Of course I can fire up bc, set scale=20 and do some
powers of 1024 division, but that's
> Unfortunately, I'll never know what the problem was.
> > >
> > > Do you use btrfs?
> >
> > Not that I'm aware of. (FWIW, if I run `mount | grep -i btrfs` (as root),
> > I get no output.)
>
> Okay, so not a btrfs issue.
>
> > >
e btrfs?
>
> Not that I'm aware of. (FWIW, if I run `mount | grep -i btrfs` (as root),
> I get no output.)
Okay, so not a btrfs issue.
> > What does "df -i" report now, after your reboot when things are
> > working?
>
> # df -i
> Filesys
w what the problem was.
>
> Do you use btrfs?
>
Not that I'm aware of. (FWIW, if I run `mount | grep -i btrfs` (as root),
I get no output.)
What does "df -i" report now, after your reboot when things are
> working?
>
# df -i
Filesystem Inodes IUsed
Hi Kynn,
On Tue, Jan 31, 2017 at 06:42:39PM -0500, Kynn Jones wrote:
> After the machine rebooted, I was able to run `dpkg-reconfigure ntp`
> without error.
>
> Unfortunately, I'll never know what the problem was.
Do you use btrfs?
What does "df -i" report now, af
at
> >the end of `apt-get`'s output, but `df` shows no shortage of space:
>
> I've no idea whether this is relevant to your case, but it's possible to
> be unable to use disk space if there are insufficient inodes left to
> store the relevant directory/file
On Tue, 31 Jan 2017 08:01:00 -0500
Kynn Jones wrote:
Hello Kynn,
>When I tried to install `ntp`, there was a "No space left on device" at
>the end of `apt-get`'s output, but `df` shows no shortage of space:
I've no idea whether this is relevant to your case, but it&
elp.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21
If not, could be things like deleted files that are still open (see
"lsof" output, look for "(deleted)". Or maybe ran out of inodes. See
"df -i" out to check that.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On 01/31/2017 08:03 AM, Eduardo M KALINOWSKI wrote:
On Ter, 31 Jan 2017, Kynn Jones wrote:
Hi everyone!
When I tried to install `ntp`, there was a "No space left on device"
at the
end of `apt-get`'s output, but `df` shows no shortage of space:
Try 'df -i', you'
On 01/31/2017 08:01 AM, Kynn Jones wrote:
Hi everyone!
When I tried to install `ntp`, there was a "No space left on device" at
the end of `apt-get`'s output, but `df` shows no shortage of space:
# df
Filesystem 1K-blocks Used Available Use% Mounted o
On Ter, 31 Jan 2017, Kynn Jones wrote:
Hi everyone!
When I tried to install `ntp`, there was a "No space left on device" at the
end of `apt-get`'s output, but `df` shows no shortage of space:
Try 'df -i', you're probably out of inodes.
--
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
Hi everyone!
When I tried to install `ntp`, there was a "No space left on device" at the
end of `apt-get`'s output, but `df` shows no shortage of space:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 381993164 206410036 156155956
On Tue, Apr 7, 2015, at 19:47, Snow Leopard wrote:
> You have a web server and monitoring system reports that you short on
> disk space. You login into web server computer and command 'df' indeed
> shows that some partition is almost full.
>
> How would you resolve t
Snow Leopard wrote:
> You have a web server and monitoring system reports that you short on disk
> space. You login into web server computer and command 'df' indeed shows that
> some partition is almost full.
>
> How would you resolve the issue if 'du' does n
On 04/07/2015 05:47 PM, Snow Leopard wrote:
> Hello,
>
> what would be a best approach for the following situation:
>
> You have a web server and monitoring system reports that you short on
> disk space. You login into web server computer and command 'df' indeed
&g
Hello,
what would be a best approach for the following situation:
You have a web server and monitoring system reports that you short on
disk space. You login into web server computer and command 'df' indeed
shows that some partition is almost full.
How would you resolve the is
afe?
>
> Will it ruin it more than a rather long output of df? Probably. It IS
> unstable after all.
That just means it is in a constant state of flux, not that the
individual packages are buggy and untested. The maintainers are
*supposed* to test their packages *before* they upload them.
all that
>with 'no-recommends' option it is absolutely safe?
Will it ruin it more than a rather long output of df? Probably. It IS
unstable after all. It depends on what matters to you. Is the output of
one command such an issue to you that you'd upgrade to an untested,
volati
On Fri, May 24, 2013 at 2:21 PM, Darac Marjal wrote:
> On Fri, May 24, 2013 at 02:07:37PM +0400, Leonid Korostyshevski wrote:
> >Hello, list!
> >I've googled [1]
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656067
> >and... a solution is?
>
> A solution to what? If you want the u
On Fri, May 24, 2013 at 02:07:37PM +0400, Leonid Korostyshevski wrote:
>Hello, list!
>I've googled [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656067
>and... a solution is?
A solution to what? If you want the updated coreutils as mentioned in
that bug report, it's in upstable
(
Hello, list!
I've googled http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656067 and...
a solution is?
Claudius Hubig wrote:
> Christian Dysthe wrote:
> > When I do 'df' (or look in System Monitor) I see the following for
> > file systems:
> > /dev/disk/by-uuid/3… 10896648 5101224 5235248 50% /
> > /dev/sda5 769760 44844 684980 7% /boot
> > /dev/s
re has been a
> difference between the three in the df output before.
Likely because the busybox-mount in the initramfs during initial boot
does not dereference the symlink, whereas the later /sbin/mount in
the fully booted system does. This is then reflected in the content
of /proc/mounts,
/home ext4
rw,errors=remount-ro 0 0
# /dev/sda8
UUID=38d6809f-8c95-43c8-9a22-23fa1cbecdd4 swap swap sw 0 0
When I do 'df' (or look in System Monitor) I see the following for file
systems:
/dev/disk/by-uuid/37de7813-0f65-41dd-b4ae-55912e454d0f 10896648 5101224
5235248 50% /
/dev/sda5 76
On 2012-10-25 13:27:33 -0200, Pedro Eugênio Rocha wrote:
> Maybe the file was opened by another user? Did you check lsof?
I didn't check with lsof, but did a "ls -la" to see whether there
were .nfs* files (usually created after removing a file that is
already open, and there wasn't any).
I would
Maybe the file was opened by another user? Did you check lsof?
Best,
On Thu, Oct 25, 2012 at 10:11 AM, Vincent Lefevre wrote:
> Hi,
>
> Yesterday, I removed a 700 MB directory over NFS with rm -rf, and
> I invoke "df" several times before and after the removal, but t
Hi,
Yesterday, I removed a 700 MB directory over NFS with rm -rf, and
I invoke "df" several times before and after the removal, but the
"Used" value only decreased by 3 MB, including more than one hour
after the operation.
Before:
Filesystem 1K-blocks Used Av
r.com/questions/289678/du-vs-df-output
oops, should have had a look :P
this pointed me to :
server:~# lsof | grep "/var" | grep "deleted"
smbd 2926 root2w REG 254,1 2665
65406 /var/log/samba/log.smbd.1 (deleted)
smbd 2926 root
I will also mention the GNU faq entry for it. Perhaps then it will
rank higher in the search engine space. :-)
http://www.gnu.org/software/coreutils/faq/#df-and-du-report-different-information
thanks, I will send this link to the sysadmin.
When I want to free up disk space used in
David Cho-Lerat wrote:
> >Google returns:
> >http://superuser.com/questions/289678/du-vs-df-output
I will also mention the GNU faq entry for it. Perhaps then it will
rank higher in the search engine space. :-)
http://www.gnu.org/software/coreutils/faq/#df-and-du-report-different
tune2fs -l /dev/md0 | grep "Reserved block count"
Sorry, I forgot to mention that the result will be in Blocks. You can
get the block size (in Bytes) with:
tune2fs -l /dev/md0 | grep "Block size"
Bye.
cool. So :
server:~# tune2fs -l /dev/mapper/vg00-var | grep "Reserved block count"
Res
Google returns:
http://superuser.com/questions/289678/du-vs-df-output
oops, should have had a look :P
this pointed me to :
server:~# lsof | grep "/var" | grep "deleted"
smbd 2926 root2w REG 254,1 2665
65406 /var/log/samba/log.s
On 21.08.2012 18:14, Denis Witt wrote:
By the way, is there a command to see how big this reserved space
actually is on a given partition/disk ?
tune2fs -l /dev/md0 | grep "Reserved block count"
Sorry, I forgot to mention that the result will be in Blocks. You can
get the block size (in By
Hi David,
By the way, is there a command to see how big this reserved space
actually is on a given partition/disk ?
tune2fs -l /dev/md0 | grep "Reserved block count"
Replace /dev/md0 with the device you want to check.
Bye.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
w
On Tue, 21 Aug 2012 16:45:35 +0200, David Cho-Lerat wrote:
> this might be a newbie question, but can anyone tell me why "du" and
> "df" don't seem to agree :
>
> server:~# df -h /var
> FilesystemSize Used Avail Use% Mounted on
> /dev/
Hi Karl,
thanks for the prompt answer.
FYI: I always use the "-x" flag on du too, as this will not recurse down
other mounted file systems - e.g. if you have /var/cache on a separate
logical volume.
that's good to know. This doesn't change anything in this case, though :
server:~# du -h -s
On Tue, Aug 21, 2012 at 04:07:54PM +0100, Karl E. Jorgensen wrote:
> Hi
>
> On Tue, Aug 21, 2012 at 03:45:35PM +0100, David Cho-Lerat wrote:
> > Hi list,
> >
> > this might be a newbie question, but can anyone tell me
> > why "du" and "df"
Hi
On Tue, Aug 21, 2012 at 03:45:35PM +0100, David Cho-Lerat wrote:
> Hi list,
>
> this might be a newbie question, but can anyone tell me
> why "du" and "df" don't seem to agree :
>
> server:~# df -h /var
> FilesystemSize Used Avai
Hi list,
this might be a newbie question, but can anyone tell me
why "du" and "df" don't seem to agree :
server:~# df -h /var
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/vg00-var 5.0G 4.1G 624M 87% /var
server:~# du -h -s /var
1.6G/var
Keith McKenzie wrote:
> It was about cp reporting 'no space left on device', whilst df said that
> there was space available.
The OS reported "No space left on device" (or more accurately, errno 28:
ENOSPC) to cp. Rather than trying to guess whether this really meant
system or the remaining space therein. Please advise.
>
> --doug
>
>
It was about cp reporting 'no space left on device', whilst df said that
there was space available.
--
Sent from FOSS (Free Open Source Software)
Debian GNU/Linux
From: Doug
Date: Fri, 29 Jun 2012 18:41:17 -0400
> cp ... none of the options mentions determining the size of a file-
> system or the remaining space therein.
The primary function seen by the user is copying. The relative
size of the projectile and its target are only relevant to the
use
On 06/29/2012 05:29 PM, peasth...@shaw.ca wrote:
From: Dom
Date: Thu, 28 Jun 2012 16:02:45 +0100
Ok, I've just tested this. It is a FAT filesystem limitation.
/snip/
I've looked at this thread a number of times, but I was then and
still am puzzled. According to "Linux in a Nutshell," by S
From: Dom
Date: Thu, 28 Jun 2012 16:02:45 +0100
> Ok, I've just tested this. It is a FAT filesystem limitation.
Nice analysis!
> On FAT12 (and FAT16, iirc) there is a limit of 512 files in the root
> directory. Other directories don't have this limit.
I found additional information here.
h
0100
What is the output of "mount | grep sdd1" ...
peter@dalton:~$ mount | grep sdd1
/dev/sdd1 on /media/4345-A417 type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000
,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush)
... and also "df -i /dev/sdd1"?
peter@dalton
uot;mount | grep sdd1" ...
peter@dalton:~$ mount | grep sdd1
/dev/sdd1 on /media/4345-A417 type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000
,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush)
> ... and also "df -i /dev/sdd1"?
peter@dalton:~$ df -i /dev/sdd1
Filesystem
peasth...@shaw.ca wrote:
> How can df report MiBs available while cp reports
> "No space left on device"?
> peter@dalton:~$ df /media/43*
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdd1 498648 18840479808 4% /media
On 2012-06-28 09:32 +0200, Berni Elbourn wrote:
> On 28/06/12 05:45, peasth...@shaw.ca wrote:
>> How can df report MiBs available while cp reports
>> "No space left on device"?
>>
>> peter@dalton:~$ df /media/43*
>> Filesystem 1K-blocks
On 28/06/12 05:45, peasth...@shaw.ca wrote:
How can df report MiBs available while cp reports
"No space left on device"?
peter@dalton:~$ df /media/43*
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdd1 498648 18840479808 4% /media
How can df report MiBs available while cp reports
"No space left on device"?
peter@dalton:~$ df /media/43*
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdd1 498648 18840479808 4% /media/4345-A417
peter@dalton:~$ ls -l Mail.Text
-r
On Wed, Sep 1, 2010 at 2:45 PM, hugo vanwoerkom wrote:
> Hi,
>
> When I do 'df /' I get:
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/hda6 13456580 5923184 6849832 47% /
> tmpfs 253024 0
Mike Bird wrote:
On Wed September 1 2010 12:01:16 hugo vanwoerkom wrote:
But that does not have the device:
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
/dev/sd
On Wed September 1 2010 12:01:16 hugo vanwoerkom wrote:
> But that does not have the device:
>
> rootfs / rootfs rw 0 0
> none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
> none /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> udev /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
> /dev/sda6 / ex
Mike Bird wrote:
On Wed September 1 2010 11:45:14 hugo vanwoerkom wrote:
What other way is there other than df to find where the root fs is mounted?
"cat /proc/mounts" is authoritative even when /etc/mtab is messed up.
But that does not have the device:
rootfs / rootfs rw 0 0
On Wed September 1 2010 11:45:14 hugo vanwoerkom wrote:
> What other way is there other than df to find where the root fs is mounted?
"cat /proc/mounts" is authoritative even when /etc/mtab is messed up.
--Mike Bird
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debia
Hi,
When I do 'df /' I get:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda6 13456580 5923184 6849832 47% /
tmpfs 253024 0253024 0% /lib/init/rw
udev 10240 900 9340 9%
On 2009-09-09 13:10, Mike Castle wrote:
On Wed, Sep 9, 2009 at 9:56 AM, niclasw wrote:
I have a 1500G hard drive, encrypted.
Different commands shows different usage:
As root, from root directory:
df -m
Filesystem 1M-blocks Used Available Use% Mounted
on
/dev/mapper
Mike Castle wrote:
On Wed, Sep 9, 2009 at 9:56 AM, niclasw wrote:
I have a 1500G hard drive, encrypted. ...
Traditionally, 5% of every file system is reserved for root to do with
as it pleases. ...
Additionally, depending on what filesystem you're using, you may have a
journal on there.
On Wed, Sep 9, 2009 at 9:56 AM, niclasw wrote:
> I have a 1500G hard drive, encrypted.
> Different commands shows different usage:
>
> As root, from root directory:
> df -m
> Filesystem 1M-blocks Used Available Use% Mounted
> on
> /dev/mapper/d
I have a 1500G hard drive, encrypted.
Different commands shows different usage:
As root, from root directory:
df -m
Filesystem 1M-blocks Used Available Use%
Mounted on
/dev/mapper/d 1390840 128452535665 98% /
That is 1284G used of 1391G which
On Mon, 20 Jul 2009 20:22:04 +0200
Johannes Wiedersich wrote:
> Eduardo M KALINOWSKI wrote:
> > On Seg, 20 Jul 2009, Micha Feigin wrote:
> >> Any ideas on where the missing gb are?
> >
> > It's the space reserved for root.
> >
> > http://www.andremiller.net/content/recovering-reserved-space-ext
On 2009-07-20 12:12, Micha Feigin wrote:
For some reason the output for my main disk as given by df doesn't add up:
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 142G 123G 12G 92% /
That's a whole lot, just for root. Is /home on a separate part
Eduardo M KALINOWSKI wrote:
> On Seg, 20 Jul 2009, Micha Feigin wrote:
>> Any ideas on where the missing gb are?
>
> It's the space reserved for root.
>
> http://www.andremiller.net/content/recovering-reserved-space-ext2-and-ext3-filesystems
I wouldn't recommend that approach for / though. 5% of
On Seg, 20 Jul 2009, Micha Feigin wrote:
For some reason the output for my main disk as given by df doesn't add up:
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 142G 123G 12G 92% /
142g - (123g + 12g) = 7g
it seems that I have 7gb missing on the disk
1 - 100 of 323 matches
Mail list logo
