Quoting Marc Shapiro via Dng (dng@lists.dyne.org):
> On 3/19/21 8:31 PM, tempforever via Dng wrote:
> >
> >To find files last modified in January:
> >(adjust the dates as needed; on Mar. 19 this should locate files dated
> >Jan 1 - 31 but it could be off a day or so)
> >
> >cd /media/archives
>
On 3/19/21 8:31 PM, tempforever via Dng wrote:
To find files last modified in January:
(adjust the dates as needed; on Mar. 19 this should locate files dated
Jan 1 - 31 but it could be off a day or so)
cd /media/archives
find -type f -mtime -78 -mtime +46 -ls
Thank you!
That found the
Marc Shapiro via Dng wrote:
>
> On 3/15/21 6:31 AM, Hendrik Boom wrote:
>> On Sun, Mar 14, 2021 at 10:28:32PM -0700, Marc Shapiro via Dng wrote:
>>> On 3/14/21 10:09 PM, Ludovic Bellière wrote:
I assume you read the man page of fsck, as it's return code is what you
want to pay attention
On Sat, 20 Mar 2021 15:13:39 +0100
Bernard Rosset via Dng wrote:
> Marc,
>
> So far, the only factual data does not show any problem, and the only
> input stating something is wrong is actually you saying that.
Hallo Bernard,
perhaps you missed these lines within the mess of pasted output,
Marc,
So far, the only factual data does not show any problem, and the only
input stating something is wrong is actually you saying that.
My previous piece of advice with sfill was to kinda force *all* the free
space to be allocated, then released... Kinda desperate measure, which
would
How do you create those backup archives? Do you use a tool?
On Fri, 19 Mar 2021 18:38:49 -0700
Marc Shapiro via Dng wrote:
>
> These are backup archives. No one is using them after they are
> created (unless I screw up and accidentally wipe out an entire
> partition, again).
>
>
> Marc
On 3/16/21 2:06 PM, Ralph Ronnquist via Dng wrote:
On Tue, 16 Mar 2021 07:41:42 -0700
Marc Shapiro via Dng wrote:
...
tmpfs 2466616 24 2466592 1% /run/user/1001
tmpfs 2466616 24 2466592 1% /run/user/1002
tmpfs 2466616 32 2466584 1% /run/user/1000
Is it possible that one of the users runs
On 3/16/21 11:17 AM, g4sra via Dng wrote:
‐‐‐ Original Message ‐‐‐
On Tuesday, March 16, 2021 2:32 PM, Marc Shapiro via Dng
wrote:
On 3/16/21 2:32 AM, g4sra via Dng wrote:
--snip--
With your removable drive attached and mounted...
Paste the outputs of 'mount' and 'df' when run
On Tue, 16 Mar 2021 07:41:42 -0700
Marc Shapiro via Dng wrote:
> ...
> tmpfs 2466616 24 2466592 1% /run/user/1001
> tmpfs 2466616 24 2466592 1% /run/user/1002
> tmpfs 2466616 32 2466584 1% /run/user/1000
Is it possible that one of the users runs some program that holds
on to cached directory
‐‐‐ Original Message ‐‐‐
On Tuesday, March 16, 2021 2:32 PM, Marc Shapiro via Dng
wrote:
On 3/16/21 2:32 AM, g4sra via Dng wrote:
--snip--
With your removable drive attached and mounted...
Paste the outputs of 'mount' and 'df' when run as root.
The drive in question is
On 3/16/21 4:45 AM, Florian Zieboll via Dng wrote:
Just to doube check for "human error": Does the output of 'df' match with the
output of 'du -sc /path/to/mountpoint/'?
The drive in question is /dev/sdb1/ mounteded on /dev/media/. Not an
exact match, but not off by 200GB, either.
On 3/16/21 2:32 AM, g4sra via Dng wrote:
<--snip-->
With your removable drive attached and mounted...
Paste the outputs of 'mount' and 'df' when run as root.
The drive in question is /dev/sdb1.
root:/home/marc# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc
Just to doube check for "human error": Does the output of 'df' match with the
output of 'du -sc /path/to/mountpoint/'?
--
[message sent otg]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
On Tue, Mar 16, 2021 at 04:57:57AM +0100, Ludovic Bellière wrote:
>
>
> On Mon, 15 Mar 2021 20:36:28 -0700
> Marc Shapiro via Dng wrote:
>
> > I'm not familiar with sfill. What does it do and what package is it
> > in. It is not currently installed here.
> >
> > Marc
>
> sfill is part of
On Tue, Mar 16, 2021 at 04:57:57AM +0100, Ludovic Bellière wrote:
>
>
> On Mon, 15 Mar 2021 20:36:28 -0700
> Marc Shapiro via Dng wrote:
>
> > I'm not familiar with sfill. What does it do and what package is it
> > in. It is not currently installed here.
> >
> > Marc
>
> sfill is part of
<--snip-->
With your removable drive attached and mounted...
Paste the outputs of 'mount' and 'df' when run as root.
publickey - g4sra@protonmail.com - 0x42E94623.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
On Mon, 15 Mar 2021 20:36:28 -0700
Marc Shapiro via Dng wrote:
> I'm not familiar with sfill. What does it do and what package is it
> in. It is not currently installed here.
>
> Marc
sfill is part of secure-delete. rm doesn't actually remove data, it
just remove all links to it leaving
On 3/15/21 2:48 AM, Bernard Rosset via Dng wrote:
You are correct. I used '+L' NOT '-L'.
I would add -nP -> "lsof -nP +L1"
If negative, I would go for the ugly path, grep'ing lsof's output on
"deleted" or "(deleted)".
Past this point, if space of alleged deleted files is not cleared... I
On 3/15/21 8:23 PM, Arnt Karlsen wrote:
On Mon, 15 Mar 2021 19:54:20 -0700, Marc wrote in message
<74553f6b-2616-70e1-e742-1ce9275b3...@gmail.com>:
On 3/15/21 6:31 AM, Hendrik Boom wrote:
On Sun, Mar 14, 2021 at 10:28:32PM -0700, Marc Shapiro via Dng
wrote:
On 3/14/21 10:09 PM, Ludovic
On Mon, 15 Mar 2021 19:54:20 -0700, Marc wrote in message
<74553f6b-2616-70e1-e742-1ce9275b3...@gmail.com>:
> On 3/15/21 6:31 AM, Hendrik Boom wrote:
> > On Sun, Mar 14, 2021 at 10:28:32PM -0700, Marc Shapiro via Dng
> > wrote:
> >> On 3/14/21 10:09 PM, Ludovic Bellière wrote:
> >>> I assume
On 3/15/21 6:31 AM, Hendrik Boom wrote:
On Sun, Mar 14, 2021 at 10:28:32PM -0700, Marc Shapiro via Dng wrote:
On 3/14/21 10:09 PM, Ludovic Bellière wrote:
I assume you read the man page of fsck, as it's return code is what you
want to pay attention to.
As for lsof, the correct parameters
On 3/15/21 12:55 AM, Steve Litt wrote:
Wait!!!
Make sure you run only a non-destructive fsck. If the non-destructive
fsck shows no problem, do the following...
First run the sync command. The sync command forces all caches to be
written to their respective files.
If they're on a removeable
You are correct. I used '+L' NOT '-L'.
I would add -nP -> "lsof -nP +L1"
If negative, I would go for the ugly path, grep'ing lsof's output on
"deleted" or "(deleted)".
Past this point, if space of alleged deleted files is not cleared... I
wonder. Even ext2 should do the trick.
If not ext4,
On Sun, 14 Mar 2021 20:39:51 -0700
Marc Shapiro via Dng wrote:
>
> On 3/14/21 8:33 PM, Ludovic Bellière wrote:
> > Run fsck to make sure your disk isn't corrupted or damaged.
> > Afterward, your lost+found might get populated with the stuff that
> > occupies the space, done so in order for you
Wait!!!
Make sure you run only a non-destructive fsck. If the non-destructive
fsck shows no problem, do the following...
First run the sync command. The sync command forces all caches to be
written to their respective files.
If they're on a removeable drive, my next step after sync would be to
On Sun, 14 Mar 2021 22:28:32 -0700
Marc Shapiro via Dng wrote:
> > It may also be possible that the files you removed have other
> > references on your file system, aka. hard links. To find them, you
> > would need to know the inode number, either by using `stat` or `ls
> > -i`. You can then
On 3/14/21 10:09 PM, Ludovic Bellière wrote:
I assume you read the man page of fsck, as it's return code is what you
want to pay attention to.
As for lsof, the correct parameters would be `lsof +aL1 /dev/sdx. It
should have thrown an error were you to use `lsof -L1`. If lsof returns
nothing,
I assume you read the man page of fsck, as it's return code is what you
want to pay attention to.
As for lsof, the correct parameters would be `lsof +aL1 /dev/sdx. It
should have thrown an error were you to use `lsof -L1`. If lsof returns
nothing, your drive is most likely corrupted.
It may also
On 3/14/21 8:33 PM, Ludovic Bellière wrote:
Run fsck to make sure your disk isn't corrupted or damaged. Afterward,
your lost+found might get populated with the stuff that occupies the
space, done so in order for you to review.
Already looked in lost+found. Nothing there.
Tried fsck. It
Run fsck to make sure your disk isn't corrupted or damaged. Afterward,
your lost+found might get populated with the stuff that occupies the
space, done so in order for you to review.
On Sun, 14 Mar 2021 20:10:03 -0700
Marc Shapiro via Dng wrote:
> I had some large files (over 200GB in total
30 matches
Mail list logo
