Re: [git pull] first batch of ufs fixes

2017-06-18 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-18 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-17 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-17 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-16 Thread Al Viro
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)

Re: [git pull] first batch of ufs fixes

2017-06-16 Thread Al Viro
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)

Re: [git pull] first batch of ufs fixes

2017-06-16 Thread Richard Narron
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.)

Re: [git pull] first batch of ufs fixes

2017-06-16 Thread Richard Narron
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.)

Re: [git pull] first batch of ufs fixes

2017-06-15 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-15 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-14 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-14 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-14 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-14 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-13 Thread Richard Narron
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...

Re: [git pull] first batch of ufs fixes

2017-06-13 Thread Richard Narron
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...

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-12 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-11 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-11 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-11 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-11 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Linus Torvalds
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.

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Linus Torvalds
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

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Al Viro
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. > > >

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Al Viro
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. > > >

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Al Viro
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

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Richard Narron
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

Re: [git pull] first batch of ufs fixes

2017-06-10 Thread Richard Narron
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

[git pull] first batch of ufs fixes

2017-06-09 Thread Al Viro
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)

[git pull] first batch of ufs fixes

2017-06-09 Thread Al Viro
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)