On Mon, Aug 09, 2021 at 09:51:39AM +0200, Harald Dunkel wrote:
> On 8/5/21 11:13 AM, Bastien Durel wrote:
> >
> > Since then, I put the mount points directories immutable (before mount)
> >
> > fremen# mkdir /tmp/foo
> > fremen# chflags schg /tmp/foo
> > fremen# touch /tmp/foo/bar
> > touch: /tm
On 8/5/21 11:13 AM, Bastien Durel wrote:
Since then, I put the mount points directories immutable (before mount)
fremen# mkdir /tmp/foo
fremen# chflags schg /tmp/foo
fremen# touch /tmp/foo/bar
touch: /tmp/foo/bar: Operation not permitted
fremen# ls -loa /tmp/foo
total 8
drwxr-xr-x 2 root whe
Le mercredi 04 août 2021 à 14:20 -0700, Greg Thomas a écrit :
> At some point my rsync script ran while /backup wasn't mounted or
> something. The culprit was there.
Hello.
I've done that more than once, especially on NFS-mounted backups.
Since then, I put the mount points directories immutable
So I found an approximate 750MB in a directory under the /backup mount
point. Removed that and ended up with sane numbers:
grits# df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd0a 986M166M771M18%/
/dev/sd0k 57.7G 25.9G 29.0G47%/home
/dev
Thank you Todd. And I'm sorry to Paul for not reading his post more
thoroughly regarding the mount points.
At some point my rsync script ran while /backup wasn't mounted or
something. The culprit was there.
On Wed, Aug 4, 2021 at 1:41 PM Todd C. Miller wrote:
> On Wed, 04 Aug 2021 13:32:54 -0
On Wed, 04 Aug 2021 13:32:54 -0700, Greg Thomas wrote:
> I'm at a loss, I booted in single user mode, ran fsck on /dev/sd0a and it
> shows clean. I still have a large discrepancy between df and du.
Did you verify that nothing was hiding under the mount points? For
example, when booted in single
I'm at a loss, I booted in single user mode, ran fsck on /dev/sd0a and it
shows clean. I still have a large discrepancy between df and du.
On Wed, Aug 4, 2021 at 2:45 AM Greg Thomas
wrote:
> Will do, but I should add that I have done nothing on this box for a
> couple of months. The day befo
Will do, but I should add that I have done nothing on this box for a couple
of months. The day before yesterday I realized that I really needed to
backup my laptop, when I went to run my backup script I discovered that I
couldn't reach this server. When I went to troubleshoot I couldn't login
so
On Wed, Aug 04, 2021 at 12:56:57AM -0700, Greg Thomas wrote:
| I take it I'm dealing with filesystem corruption as Ali mentioned earlier?
Could be. Boot the system in single user mode or the bsd.rd
installation kernel (at the boot prompt type either 'boot -s' or 'boot
bsd.rd'). Enter the shell a
No, after the reboot I'm still in the same situation. As mentioned earlier
I deleted /bsd.sp so I have a little more free space.
grits# df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd0a 986M916M 20.1M98%/
/dev/sd0k 57.7G 25.9G 29.0G47%/hom
On Tue, Aug 03, 2021 at 10:57:42PM -0700, Greg Thomas wrote:
> I thought Paul's advice only applies if I was trying to figure it out
> before rebooting? I'd already rebooted before sending my first email.
OK, did the free space come back in df after reboot? If so, then it's
programs having open
I thought Paul's advice only applies if I was trying to figure it out
before rebooting? I'd already rebooted before sending my first email.
On Tue, Aug 3, 2021 at 10:40 PM Otto Moerbeek wrote:
> On Tue, Aug 03, 2021 at 12:39:54PM -0700, Greg Thomas wrote:
>
> > I'm definitely suffering from f
On Tue, Aug 03, 2021 at 12:39:54PM -0700, Greg Thomas wrote:
> I'm definitely suffering from filesystem corruption on root. I had
> rebooted last night with no change.
>
> I have no options for mounting root.
>
> grits# cat /etc/fstab
> 16a27b4b4549ce04.b none swap sw
> 16a27b4b4549ce04.a / ffs
I'm definitely suffering from filesystem corruption on root. I had
rebooted last night with no change.
I have no options for mounting root.
grits# cat /etc/fstab
16a27b4b4549ce04.b none swap sw
16a27b4b4549ce04.a / ffs rw 1 1
16a27b4b4549ce04.k /home ffs rw,nodev,nosuid 1 2
16a27b4b4549ce04.d /t
I also suspected that it is a filesystem corruption.
Do you have `async` mount option on your root?
Sebastien Marie wrote:
> On Tue, Aug 03, 2021 at 10:03:44AM +0200, Paul de Weerd wrote:
> > df shows you how much data you can write to an fs, while du shows the
> > disk usage of files it can find
On Tue, Aug 03, 2021 at 10:03:44AM +0200, Paul de Weerd wrote:
> df shows you how much data you can write to an fs, while du shows the
> disk usage of files it can find. If it can't find a file (because
> it's been deleted), it won't account for it. But if it's been deleted
> and still held open
df shows you how much data you can write to an fs, while du shows the
disk usage of files it can find. If it can't find a file (because
it's been deleted), it won't account for it. But if it's been deleted
and still held open by some process, it would still consume disk
space.
So it looks like a
grits# df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd0a 986M936M162K 100%/
/dev/sd0k 57.7G 23.7G 31.1G43%/home
/dev/sd0d 3.9G 10.0K3.7G 0%/tmp
/dev/sd0f 5.8G1.1G4.4G21%/usr
/dev/sd0g 986M234M
18 matches
Mail list logo
