scan_ffs(8) and FFS2 filesystems

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

scan_ffs(8) and FFS2 filesystems

Jeremie Courreges-Anglas-2


I think it's fair to give the user a chance to understand why
scan_ffs(8) won't help in this case.

ok?


--- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
+++ scan_ffs.8 Fri Feb  8 21:31:10 2019
@@ -136,6 +136,7 @@ you out of a jam when they happen.
 .Sh SEE ALSO
 .Xr disklabel 8
 .Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
+It is not perfect, does not support FFS2 filesystems,
+and could do a lot more things with date/time information
 in the superblocks it finds, but this program has saved more than one butt,
 more than once.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

Jason McIntyre-2
On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
>
>
> I think it's fair to give the user a chance to understand why
> scan_ffs(8) won't help in this case.
>
> ok?
>

hi.

i'm not sure if it's a bug, but it sure seems relevant. i would be
tempted to be much more upfront about this (DESCRIPTION), way before you
start tearing hair out...

like just say upfront, scan_ffs does not support ffs2 filesystems.

jmc

>
> --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> +++ scan_ffs.8 Fri Feb  8 21:31:10 2019
> @@ -136,6 +136,7 @@ you out of a jam when they happen.
>  .Sh SEE ALSO
>  .Xr disklabel 8
>  .Sh BUGS
> -It is not perfect, and could do a lot more things with date/time information
> +It is not perfect, does not support FFS2 filesystems,
> +and could do a lot more things with date/time information
>  in the superblocks it finds, but this program has saved more than one butt,
>  more than once.
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

Theo de Raadt-2
Jason McIntyre <[hidden email]> wrote:

> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
> >
> >
> > I think it's fair to give the user a chance to understand why
> > scan_ffs(8) won't help in this case.
> >
> > ok?
> >
>
> hi.
>
> i'm not sure if it's a bug, but it sure seems relevant. i would be
> tempted to be much more upfront about this (DESCRIPTION), way before you
> start tearing hair out...
>
> like just say upfront, scan_ffs does not support ffs2 filesystems.

true.  it should be stated in a formal way.

"It is not perfect"

Yuck...

"one butt"?

This is below our standard.


> > --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> > +++ scan_ffs.8 Fri Feb  8 21:31:10 2019
> > @@ -136,6 +136,7 @@ you out of a jam when they happen.
> >  .Sh SEE ALSO
> >  .Xr disklabel 8
> >  .Sh BUGS
> > -It is not perfect, and could do a lot more things with date/time information
> > +It is not perfect, does not support FFS2 filesystems,
> > +and could do a lot more things with date/time information
> >  in the superblocks it finds, but this program has saved more than one butt,
> >  more than once.
> >
> > --
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

Jeremie Courreges-Anglas-2
On Fri, Feb 08 2019, "Theo de Raadt" <[hidden email]> wrote:

> Jason McIntyre <[hidden email]> wrote:
>
>> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
>> >
>> >
>> > I think it's fair to give the user a chance to understand why
>> > scan_ffs(8) won't help in this case.
>> >
>> > ok?
>> >
>>
>> hi.
>>
>> i'm not sure if it's a bug, but it sure seems relevant. i would be
>> tempted to be much more upfront about this (DESCRIPTION), way before you
>> start tearing hair out...
>>
>> like just say upfront, scan_ffs does not support ffs2 filesystems.
>
> true.  it should be stated in a formal way.

Looks like a better approach indeed.

> "It is not perfect"
>
> Yuck...
>
> "one butt"?
>
> This is below our standard.

yep

So here's a three parts diff
1. kill useless .TH line present since rev. 1.1
2. document the lack of FFS2 support in DESCRIPTION
3. remove BUGS

Rationale for 3: after trimming the fluff from BUGS, you end up with:

  .Nm
  could do a lot more things with date/time information in the
  superblocks it finds.

The FFS superblock contains three "time" fields:
- fs_ffs1_time "last time written"
- fs_time "last time written"
- fs_fscktime "last time fsck(8)ed"

Printing fs_fscktime doesn't look useful to me.  fs_ffs1_time and
fs_time are supposed to contain the same value, if I read ffs_vfsops.c
correctly.  The difference is that fs_ffs1_time is an int32_t and
fs_time is an int64_t.  While this may need care regarding Y2038,
this is a problem with FFS, not scan_ffs(8).

Thoughts/oks?


--- scan_ffs.8.~1.16.~ Fri Feb  8 21:56:34 2019
+++ scan_ffs.8 Fri Feb  8 23:08:00 2019
@@ -23,7 +23,6 @@
 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.\" .TH scan_ffs 8
 .Dd $Mdocdate: March 23 2008 $
 .Dt SCAN_FFS 8
 .Os
@@ -48,6 +47,10 @@ on the disk.
 It has various options to make it go faster, and to print out
 information to help in the reconstruction of the disklabel.
 .Pp
+Note that
+.Nm
+does not recognize FFS2 partitions.
+.Pp
 The options are as follows:
 .Bl -tag -width Ds
 .It Fl b Ar begin
@@ -135,7 +138,3 @@ If you can't have backups, at least have funky tools t
 you out of a jam when they happen.
 .Sh SEE ALSO
 .Xr disklabel 8
-.Sh BUGS
-It is not perfect, and could do a lot more things with date/time information
-in the superblocks it finds, but this program has saved more than one butt,
-more than once.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

Jason McIntyre-2
On Fri, Feb 08, 2019 at 11:11:31PM +0100, Jeremie Courreges-Anglas wrote:

> On Fri, Feb 08 2019, "Theo de Raadt" <[hidden email]> wrote:
> > Jason McIntyre <[hidden email]> wrote:
> >
> >> On Fri, Feb 08, 2019 at 09:35:35PM +0100, Jeremie Courreges-Anglas wrote:
> >> >
> >> >
> >> > I think it's fair to give the user a chance to understand why
> >> > scan_ffs(8) won't help in this case.
> >> >
> >> > ok?
> >> >
> >>
> >> hi.
> >>
> >> i'm not sure if it's a bug, but it sure seems relevant. i would be
> >> tempted to be much more upfront about this (DESCRIPTION), way before you
> >> start tearing hair out...
> >>
> >> like just say upfront, scan_ffs does not support ffs2 filesystems.
> >
> > true.  it should be stated in a formal way.
>
> Looks like a better approach indeed.
>
> > "It is not perfect"
> >
> > Yuck...
> >
> > "one butt"?
> >
> > This is below our standard.
>
> yep
>
> So here's a three parts diff
> 1. kill useless .TH line present since rev. 1.1

yep

> 2. document the lack of FFS2 support in DESCRIPTION

yep, though i'd skip the "note that" blurb.

why not

        .Pp
        .Nm
        works only on FFS file systems,
        not FFS2 file systems.

> 3. remove BUGS
>

i'm less sure here. i'd leave it to the author's discretion, but if it
really is useless (i can't judge), fair enough.

jmc

> Rationale for 3: after trimming the fluff from BUGS, you end up with:
>
>   .Nm
>   could do a lot more things with date/time information in the
>   superblocks it finds.
>
> The FFS superblock contains three "time" fields:
> - fs_ffs1_time "last time written"
> - fs_time "last time written"
> - fs_fscktime "last time fsck(8)ed"
>
> Printing fs_fscktime doesn't look useful to me.  fs_ffs1_time and
> fs_time are supposed to contain the same value, if I read ffs_vfsops.c
> correctly.  The difference is that fs_ffs1_time is an int32_t and
> fs_time is an int64_t.  While this may need care regarding Y2038,
> this is a problem with FFS, not scan_ffs(8).
>
> Thoughts/oks?
>
>
> --- scan_ffs.8.~1.16.~ Fri Feb  8 21:56:34 2019
> +++ scan_ffs.8 Fri Feb  8 23:08:00 2019
> @@ -23,7 +23,6 @@
>  .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
>  .\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  .\"
> -.\" .TH scan_ffs 8
>  .Dd $Mdocdate: March 23 2008 $
>  .Dt SCAN_FFS 8
>  .Os
> @@ -48,6 +47,10 @@ on the disk.
>  It has various options to make it go faster, and to print out
>  information to help in the reconstruction of the disklabel.
>  .Pp
> +Note that
> +.Nm
> +does not recognize FFS2 partitions.
> +.Pp
>  The options are as follows:
>  .Bl -tag -width Ds
>  .It Fl b Ar begin
> @@ -135,7 +138,3 @@ If you can't have backups, at least have funky tools t
>  you out of a jam when they happen.
>  .Sh SEE ALSO
>  .Xr disklabel 8
> -.Sh BUGS
> -It is not perfect, and could do a lot more things with date/time information
> -in the superblocks it finds, but this program has saved more than one butt,
> -more than once.
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
>

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

gwes-2
In reply to this post by Jeremie Courreges-Anglas-2


On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:

>
> I think it's fair to give the user a chance to understand why
> scan_ffs(8) won't help in this case.
>
> ok?
>
>
> --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> +++ scan_ffs.8 Fri Feb  8 21:31:10 2019
> @@ -136,6 +136,7 @@ you out of a jam when they happen.
>   .Sh SEE ALSO
>   .Xr disklabel 8
>   .Sh BUGS
> -It is not perfect, and could do a lot more things with date/time information
> +It is not perfect, does not support FFS2 filesystems,
> +and could do a lot more things with date/time information
>   in the superblocks it finds, but this program has saved more than one butt,
>   more than once.
>
Scan_ffs checks for the the magic number of the superblock.


--- scan_ffs.c  23 Nov 2015 19:19:30 -0000      1.21
+++ scan_ffs.c  9 Feb 2019 02:13:48 -0000
@@ -67,7 +67,8 @@ ufsscan(int fd, daddr_t beg, daddr_t end

                 for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
                         sb = (struct fs*)(&buf[n]);
-                       if (sb->fs_magic == FS_MAGIC) {
+                       if (sb->fs_magic == FS_UFS1_MAGIC ||
+                           sb->fs_magic == FS_UFS2_MAGIC) {
                                 if (flags & FLAG_VERBOSE)
                                         printf("block %lld id %x,%x
size %d\n",
                                             (long long)(blk + (n/512)),
                sb->fs_magic == FS_UFS2_MAGIC) {
fixes it.

Reply | Threaded
Open this post in threaded view
|

Re: scan_ffs(8) and FFS2 filesystems

Ted Unangst-6
gwes wrote:

>
>
> On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:
> >
> > I think it's fair to give the user a chance to understand why
> > scan_ffs(8) won't help in this case.
> >
> > ok?
> >
> >
> > --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> > +++ scan_ffs.8 Fri Feb  8 21:31:10 2019
> > @@ -136,6 +136,7 @@ you out of a jam when they happen.
> >   .Sh SEE ALSO
> >   .Xr disklabel 8
> >   .Sh BUGS
> > -It is not perfect, and could do a lot more things with date/time information
> > +It is not perfect, does not support FFS2 filesystems,
> > +and could do a lot more things with date/time information
> >   in the superblocks it finds, but this program has saved more than one butt,
> >   more than once.
> >
> Scan_ffs checks for the the magic number of the superblock.
>
>
> --- scan_ffs.c  23 Nov 2015 19:19:30 -0000      1.21
> +++ scan_ffs.c  9 Feb 2019 02:13:48 -0000
> @@ -67,7 +67,8 @@ ufsscan(int fd, daddr_t beg, daddr_t end
>
>                  for (n = 0; n < (SBSIZE * SBCOUNT); n += 512){
>                          sb = (struct fs*)(&buf[n]);
> -                       if (sb->fs_magic == FS_MAGIC) {
> +                       if (sb->fs_magic == FS_UFS1_MAGIC ||
> +                           sb->fs_magic == FS_UFS2_MAGIC) {
>                                  if (flags & FLAG_VERBOSE)
>                                          printf("block %lld id %x,%x
> size %d\n",
>                                              (long long)(blk + (n/512)),
>                 sb->fs_magic == FS_UFS2_MAGIC) {
> fixes it.

Did you test this? The superblock has a different offset in UFS2.