On Mon, May 23, 2022 at 09:47:37PM -0700, Chuck Silvers wrote:
> So what can we do about this? There aren't any really great
> options. But the only change which will guarantee that all old
> NetBSD releases (which do not know about extend attributes) will
> not corrupt file system images
Date:Wed, 25 May 2022 07:52:29 -0300
From:Crystal Kolipe
Message-ID:
| FreeBSD and DragonflyBSD are basically the same as NetBSD in terms of
| disklabel layout, so that issue doesn't exists.
If all OpenBSD are doing is using some otherwise unused space,
then we
On Wed, May 25, 2022 at 02:00:44AM -0700, Chuck Silvers wrote:
> On Tue, May 24, 2022 at 07:51:08AM -0400, Greg Troxel wrote:
> > And same questions for the other active BSD variants, which I think is
> > mostly OpenBSD and Dragonfly these days but I have lost track.
>
> OpenBSD UFS2 appears to
On Tue, May 24, 2022 at 07:51:08AM -0400, Greg Troxel wrote:
>
> Chuck Silvers writes:
>
> > The introduction in NetBSD's implementation of UFS2 of the extended
> > attribute code from FreeBSD has introduced a compatibility problem
> > with previous releases of NetBSD. The explanation of this
On Tue, May 24, 2022 at 06:25:34AM -, Michael van Elst wrote:
> c...@chuq.com (Chuck Silvers) writes:
>
> > - fsck will take a new option "-c ea" to specify that an existing UFS2
> > file system should be converted to support extended attributes
> > (ie. converted to UFS2ea). This
Chuck Silvers writes:
> The introduction in NetBSD's implementation of UFS2 of the extended
> attribute code from FreeBSD has introduced a compatibility problem
> with previous releases of NetBSD. The explanation of this problem is
> a bit involved and requires knowing some history, so please
On Fri, Oct 16, 2020 at 12:26:03AM +0900, Rin Okuyama wrote:
> On 2020/10/15 20:27, Thomas Klausner wrote:
> > On Thu, Oct 15, 2020 at 12:03:36PM +0100, Patrick Welche wrote:
> > > Is yours a ryzen system? (mine is, and it has filesystem issues - just
> > > trying to see why it is not a common
On 2020/10/15 20:27, Thomas Klausner wrote:
On Thu, Oct 15, 2020 at 12:03:36PM +0100, Patrick Welche wrote:
Is yours a ryzen system? (mine is, and it has filesystem issues - just
trying to see why it is not a common issue)
Yes:
There was a report on Twitter (in Japanese):
On Thu, Oct 15, 2020 at 12:03:36PM +0100, Patrick Welche wrote:
> Is yours a ryzen system? (mine is, and it has filesystem issues - just
> trying to see why it is not a common issue)
Yes:
# cpuctl identify 0
cpu0: highest basic info 000d
cpu0: highest extended info 801f
cpu0: "AMD Ryzen
On Sun, Oct 11, 2020 at 11:19:16PM +0200, Thomas Klausner wrote:
> I've had serious file system corruption. Mostly in mercurial and
> sqlite3 databases, but also in normal files.
> Anyone else having problems?
Is yours a ryzen system? (mine is, and it has filesystem issues - just
trying to see
On Mon, Oct 12, 2020 at 06:39:48AM +0200, Martin Husemann wrote:
> On Sun, Oct 11, 2020 at 11:19:16PM +0200, Thomas Klausner wrote:
> > I don't know enough about the internals of the hg and sqlite3, but I
> > also saw a broken zip archive and had a good copy for comparison. In
> > that case, a
On Mon, Oct 12, 2020 at 06:39:48AM +0200, Martin Husemann wrote:
> Do you know the file offset where the corruption started?
I don't have that one any more, but I found a different one.
In this case, the range of bytes from 1291124737-1291157504 (32768
bytes) is zeroed out. 1291124737 =
On Sun, Oct 11, 2020 at 11:19:16PM +0200, Thomas Klausner wrote:
> Hi!
>
> I've recently updated from 9.99.73 from Sep 17 to one of Oct 5.
>
> I've had serious file system corruption. Mostly in mercurial and
> sqlite3 databases, but also in normal files.
what platform is this on?
> Some of
On Sun, Oct 11, 2020 at 11:19:16PM +0200, Thomas Klausner wrote:
> I don't know enough about the internals of the hg and sqlite3, but I
> also saw a broken zip archive and had a good copy for comparison. In
> that case, a block of 256 bytes was zero instead of the real data.
Do you know the file
14 matches
Mail list logo
