[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YQnU5m/ur+0D5MfJ@casper.infradead.org>
Date: Wed, 4 Aug 2021 00:44:38 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Leonidas P. Papadakos" <papadakospan@...il.com>,
Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
zajec5@...il.com, "Darrick J. Wong" <djwong@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hans de Goede <hdegoede@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [GIT PULL] vboxsf fixes for 5.14-1
On Tue, Aug 03, 2021 at 06:48:36PM -0400, Theodore Ts'o wrote:
> So over the weekend, I decided to take efforts into my own hands, and
> made the relatively simple changes to fstests needed to add support
> for ntfs and ntfs3 file systems. The results show that the number
> fstests failures in ntfs3 is 23% *more* than ntfs. This includes a
> potential deadlock bug, and generic/475 reliably livelocking. Ntfs3
> is also currently not container compatible, because it's not properly
> handling user namespaces.
I don't understand how so many ntfs-classic xfstests pass:
config NTFS_RW
bool "NTFS write support"
depends on NTFS_FS
help
This enables the partial, but safe, write support in the NTFS driver.
The only supported operation is overwriting existing files, without
changing the file length. No file or directory creation, deletion or
renaming is possible. Note only non-resident files can be written to
so you may find that some very small files (<500 bytes or so) cannot
be written to.
Are the tests really passing, or just claiming to pass?
Powered by blists - more mailing lists