All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Mioso <mrkiko.rs@gmail.com>
To: "Artem S. Tashkinov" <aros@gmx.com>
Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
	ntfs3@lists.linux.dev
Subject: Re: NTFS driver excessive logging by default: Correct links count
Date: Mon, 15 Apr 2024 12:11:26 +0200	[thread overview]
Message-ID: <Zhz9TveeujvHCo96@rivendell> (raw)
In-Reply-To: <48b67a18-878a-4068-bf3d-bc76960ecc59@gmx.com>

On Thu, Apr 11, 2024 at 01:01:21PM +0000, Artem S. Tashkinov wrote:
> 
> 
> On 4/11/24 11:00, Konstantin Komarov wrote:
> > On 27.03.2024 13:28, Artem S. Tashkinov wrote:
> > > Hello,
> > > 
> > > I hoped 6.8.2 would have the issue fixed but no luck.
> > > 
> > > Whenever I list files on my NTFS partitions I get a lot of SPAM in
> > > dmesg, e.g.:
> > > 
> > > ntfs3: sda3: ino=14c, Correct links count -> 1.
> > > ntfs3: sda3: ino=73, Correct links count -> 1.
> > > ntfs3: sda3: ino=167, Correct links count -> 1.
> > > ntfs3: sda3: ino=d9, Correct links count -> 1.
> > > ntfs3: sda3: ino=d5, Correct links count -> 1.
> > > 
> > > And the partition in question has been fully chkdsk'ed and has no issues.
> > > 
> > > Please fix.
> > > 
> > > Best regards,
> > > Artem
> > 
> > Hello Artem,
> > 
> > Probably your volume contains non-critical (minor) errors.
> > chkdsk does not show them, but fixes them if you specify /f.
> > 
> 
> I have run chkdsk /f twice and I'm still getting these errors:
> 
> ntfs3: sda7: ino=14c, Correct links count -> 1.
> ntfs3: sda7: ino=73, Correct links count -> 1.
> ntfs3: sda7: ino=d9, Correct links count -> 1.
> ntfs3: sda7: ino=98, Correct links count -> 1.
> ntfs3: sda7: ino=d5, Correct links count -> 1.
> ntfs3: sda7: ino=f2, Correct links count -> 1.
> ntfs3: sda7: ino=e1, Correct links count -> 1.
> ntfs3: sda7: ino=e8, Correct links count -> 1.
> ntfs3: sda7: ino=e5, Correct links count -> 1.
> ntfs3: sda7: ino=e4, Correct links count -> 1.
> 
> 1. It's a bug
You are probably right, but let's make it explicit: you're assuming no bugs can be present in chkdsk.exe.
> 2. Even if it's not a bug (I'm 100% sure there is one since chkdsk does
> not fix it), there must be a single message per partition per boot at most.
I might be wrong, but I see different ino values, so limiting the messages at one per boot wouldn't probably make much sense or am I mistaken?

Thanks,
Enrico

> 
> Regards,
> Artem
> 

  reply	other threads:[~2024-04-15 10:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 10:28 NTFS driver excessive logging by default: Correct links count Artem S. Tashkinov
2024-04-11 11:00 ` Konstantin Komarov
2024-04-11 13:01   ` Artem S. Tashkinov
2024-04-15 10:11     ` Enrico Mioso [this message]
2024-04-15 14:12       ` Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zhz9TveeujvHCo96@rivendell \
    --to=mrkiko.rs@gmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=aros@gmx.com \
    --cc=ntfs3@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.