On Sun, 18 Jun 2017, Al Viro wrote:
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
They seem to work fine with the simple testing that I do.
I
On Sun, 18 Jun 2017, Al Viro wrote:
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
They seem to work fine with the simple testing that I do.
I
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
> On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
>
> > The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
> > They seem to work fine with the simple testing that I do.
> >
> > I tested all 3 BSDs, FreeBSD
On Sat, Jun 17, 2017 at 03:15:48AM +0100, Al Viro wrote:
> On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
>
> > The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
> > They seem to work fine with the simple testing that I do.
> >
> > I tested all 3 BSDs, FreeBSD
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
> The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
> They seem to work fine with the simple testing that I do.
>
> I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2
> filesystems, 44bsd (ufs1)
On Fri, Jun 16, 2017 at 07:29:00AM -0700, Richard Narron wrote:
> The 8 patches in the ufs-fixes group were applied to Linux 4.12-rc5.
> They seem to work fine with the simple testing that I do.
>
> I tested all 3 BSDs, FreeBSD 11.0, OpenBSD 6.1 and NetBSD 7.1 using 2
> filesystems, 44bsd (ufs1)
On Thu, 15 Jun 2017, Al Viro wrote:
On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote:
FWIW, it seems to work here. Said that, *BSD fsck_ffs is not worth much -
play a bit with redundancy in UFS superblock (starting with fragment
and block sizes, their ratio, logarithms, bitmasks, etc.)
On Thu, 15 Jun 2017, Al Viro wrote:
On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote:
FWIW, it seems to work here. Said that, *BSD fsck_ffs is not worth much -
play a bit with redundancy in UFS superblock (starting with fragment
and block sizes, their ratio, logarithms, bitmasks, etc.)
On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote:
> NOTE: all I have is your image *after* it had counters buggered; I don't
> know the exact sequence of operations that fucked it in your case. One
> way to trigger it is to mount/umount on OpenBSD, then mount/modify/umount
> on Linux, then
On Wed, Jun 14, 2017 at 08:11:33AM +0100, Al Viro wrote:
> NOTE: all I have is your image *after* it had counters buggered; I don't
> know the exact sequence of operations that fucked it in your case. One
> way to trigger it is to mount/umount on OpenBSD, then mount/modify/umount
> on Linux, then
On Wed, 14 Jun 2017, Al Viro wrote:
...
AFAICS, a conservative approach would be
* reject UFS_42POSTBLFMT for 44bsd ones - it's almost certainly
*not* one.
* check if fs_maxbsize is equal to frag size; treat that as
"counts are read from new location and stored both to old and
On Wed, 14 Jun 2017, Al Viro wrote:
...
AFAICS, a conservative approach would be
* reject UFS_42POSTBLFMT for 44bsd ones - it's almost certainly
*not* one.
* check if fs_maxbsize is equal to frag size; treat that as
"counts are read from new location and stored both to old and
On Tue, Jun 13, 2017 at 02:56:23PM -0700, Richard Narron wrote:
> On Tue, 13 Jun 2017, Al Viro wrote:
>
> > On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
> >
> > > Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
> > > Linux 4.12-rc5 copy of my >2GB
On Tue, Jun 13, 2017 at 02:56:23PM -0700, Richard Narron wrote:
> On Tue, 13 Jun 2017, Al Viro wrote:
>
> > On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
> >
> > > Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
> > > Linux 4.12-rc5 copy of my >2GB
On Tue, 13 Jun 2017, Al Viro wrote:
On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
Linux 4.12-rc5 copy of my >2GB file using "cp".
But later today I get the error when I copy using your "dd" method...
On Tue, 13 Jun 2017, Al Viro wrote:
On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
Linux 4.12-rc5 copy of my >2GB file using "cp".
But later today I get the error when I copy using your "dd" method...
On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
> Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
> Linux 4.12-rc5 copy of my >2GB file using "cp".
>
> But later today I get the error when I copy using your "dd" method...
>
> In any case I always get a
On Mon, Jun 12, 2017 at 05:54:06PM -0700, Richard Narron wrote:
> Earlier today I could not reproduce the OpenBSD 6.1 ufs1 fsck error after
> Linux 4.12-rc5 copy of my >2GB file using "cp".
>
> But later today I get the error when I copy using your "dd" method...
>
> In any case I always get a
On Mon, 12 Jun 2017, Al Viro wrote:
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
2GB file and creating a directory, there are errors on OpenBSD
with the fsck:
Can't reproduce...
# fsck -f
On Mon, 12 Jun 2017, Al Viro wrote:
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
2GB file and creating a directory, there are errors on OpenBSD
with the fsck:
Can't reproduce...
# fsck -f
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
> 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
> 2GB file and creating a directory, there are errors on OpenBSD
> with the fsck:
>
> OpenBSD (44bsd):
> #fsck sd0e
> ** /dev/rsd0e
> ** File system
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
> 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
> 2GB file and creating a directory, there are errors on OpenBSD
> with the fsck:
>
> OpenBSD (44bsd):
> #fsck sd0e
> ** /dev/rsd0e
> ** File system
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
> 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
> 2GB file and creating a directory, there are errors on OpenBSD
> with the fsck:
>
> OpenBSD (44bsd):
> #fsck sd0e
> ** /dev/rsd0e
> ** File system
On Sun, Jun 11, 2017 at 12:47:40PM -0700, Richard Narron wrote:
> 1) Creating an OpenBSD 6.1 (44bsd) disk and then on Linux copying a large >
> 2GB file and creating a directory, there are errors on OpenBSD
> with the fsck:
>
> OpenBSD (44bsd):
> #fsck sd0e
> ** /dev/rsd0e
> ** File system
The ufs fixes are looking good, much better than what we started with.
After applying the 8 ufs patches:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
/commit/?id=5faab9e0f03c4eef97886b45436015e107f79f5f
Copying files to FreeBSD 11.0 (ufs2) and NetBSD 7.1 (ufs2) looks
The ufs fixes are looking good, much better than what we started with.
After applying the 8 ufs patches:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
/commit/?id=5faab9e0f03c4eef97886b45436015e107f79f5f
Copying files to FreeBSD 11.0 (ufs2) and NetBSD 7.1 (ufs2) looks
On Sat, Jun 10, 2017 at 11:08 AM, Al Viro wrote:
>
> BTW, should I send an updated pull request in such situation?
It's better if you do, although in this case it was obvious that you'd
just added a single line and I could see the diffstat still match with
that addition.
On Sat, Jun 10, 2017 at 11:08 AM, Al Viro wrote:
>
> BTW, should I send an updated pull request in such situation?
It's better if you do, although in this case it was obvious that you'd
just added a single line and I could see the diffstat still match with
that addition.
But in general it just
On Sat, Jun 10, 2017 at 05:07:38PM +0100, Al Viro wrote:
> On Sat, Jun 10, 2017 at 06:03:24AM -0700, Richard Narron wrote:
>
> > 2) After creating a new filesystem on FreeBSD, then on Linux copying a
> > larger than 2GB file and creating a directory, the fsck back on FreeBSD
> > looks ok.
> >
>
On Sat, Jun 10, 2017 at 05:07:38PM +0100, Al Viro wrote:
> On Sat, Jun 10, 2017 at 06:03:24AM -0700, Richard Narron wrote:
>
> > 2) After creating a new filesystem on FreeBSD, then on Linux copying a
> > larger than 2GB file and creating a directory, the fsck back on FreeBSD
> > looks ok.
> >
>
On Sat, Jun 10, 2017 at 06:03:24AM -0700, Richard Narron wrote:
> 2) After creating a new filesystem on FreeBSD, then on Linux copying a
> larger than 2GB file and creating a directory, the fsck back on FreeBSD
> looks ok.
>
> But after going back to Linux and removing the large file and
On Sat, Jun 10, 2017 at 06:03:24AM -0700, Richard Narron wrote:
> 2) After creating a new filesystem on FreeBSD, then on Linux copying a
> larger than 2GB file and creating a directory, the fsck back on FreeBSD
> looks ok.
>
> But after going back to Linux and removing the large file and
On Fri, 9 Jun 2017, Al Viro wrote:
That's just the obvious backport fodder; I'm pretty sure that there
will be more - definitely so wrt performance and quite possibly correctness
as well.
These fixes improve the ufs code and they are a good start.
Here are a couple of bugs that still
On Fri, 9 Jun 2017, Al Viro wrote:
That's just the obvious backport fodder; I'm pretty sure that there
will be more - definitely so wrt performance and quite possibly correctness
as well.
These fixes improve the ufs code and they are a good start.
Here are a couple of bugs that still
That's just the obvious backport fodder; I'm pretty sure that there
will be more - definitely so wrt performance and quite possibly correctness
as well.
The following changes since commit a8c39544a6eb2093c04afd5005b6192bd0e880c6:
osf_wait4(): fix infoleak (2017-05-21 13:10:07 -0400)
That's just the obvious backport fodder; I'm pretty sure that there
will be more - definitely so wrt performance and quite possibly correctness
as well.
The following changes since commit a8c39544a6eb2093c04afd5005b6192bd0e880c6:
osf_wait4(): fix infoleak (2017-05-21 13:10:07 -0400)
36 matches
Mail list logo