--UoPmpPX/dBe4BELn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 07, 2004 at 04:30:36PM +0200, Rhialto wrote:
> I am trying to get dump(8) to dump to a portal-fs file. The idea is to
> dump to a dvd-writing program, so I can do multi-volume dvd dumps.
>=20
> >From /etc/portal.conf:
>=20
> dvdw            wfilter dvdw    /usr/local/sbin/dvdw %s
>=20
> There is however a difficulty.
>=20
> After the real dump is complete, the tape is re-opened, presumably to
> see that the tape drive is really done. This is done requesting READ nor
> WRITE access:

Did you mean "READ not WRITE"? Or "neither READ nor WRITE"?

> src/sbin/dump/tape.c:407
>=20
>         (void) close(tapefd);
>         while ((f =3D open(tape, 0)) < 0) {

That's opening it for READ access. O_RDONLY is zero.

>                 msg("sleeping after open failure of %s\n", tape);
>                 sleep (10);
>         }
>         if (eflag && eject) {
>                 struct mtop offl;
>=20
>                 msg("Ejecting %s\n", tape);
>                 offl.mt_op =3D MTOFFL;
>                 offl.mt_count =3D 0;
>                 (void) ioctl(f, MTIOCTOP, &offl);
>         }
>         (void) close(f);
> }
>=20
>=20
> This however seems to run afoul of the following check in the portal
> file system:
>=20
> portal_vnops.c:
>=20
>         /*
>          * Check that the mode the file is being opened for is a subset=
=20
>          * of the mode of the existing descriptor.
>          */
>         fp =3D p->p_fd->fd_ofiles[fd];
>         if (((ap->a_mode & (FREAD|FWRITE)) | fp->f_flag) !=3D fp->f_flag)=
 {
>                 portal_closefd(curlwp, fd); /* XXXNJWLWP */
>                 error =3D EACCES;
>                 goto bad;
>         }
>=20
>=20
> ap->a_mode, the requested access mode, =3D=3D FREAD - apparently somethin=
g has
> translated this in the mean time.

Yes, the system call glue turns O_ flags into F flags.

> fp->f_flag, the mode for the created file by the portal deamon, =3D=3D FW=
RITE,
> as would be expected for a wfilter.

Note that ((FREAD & (FREAD|FWRITE)) | FWRITE) =3D=3D (FREAD|FWRITE) !=3D=20
fp->f_flag.

> The condition is therefore triggered, the file is not opened (although
> the portal script dvdw is run!), and dump keeps trying again every 10
> seconds without ever succeeding.
>=20
> The result, however, is that It Won't Work(tm).
>=20
> The problem is that a wfilter should never be matched when a file is
> opened just for reading. I'll look into some patches to fix this.

No. It should be matched.

The issue is that at the time the match happens, in namei as best I can=20
tell, we don't know if the file will even be opened, much less if it's=20
being opened for read or write (or both).

I don't know enough about the procfs kernel<->server communication=20
protocol to say what should be done. But I think what you want is=20
something like a "rwfilter", that can be open either for reading or=20
writing. I suspect (but I'm really guessing) that you might also want to=20
communicate this mode to the server on startup.

Basically the problem is that by the time we get to the test you talk=20
about above, things are already wrong. The test is seeing that the file=20
descriptor we got back won't work for the open we want.

The alternative is to get dump to be able to open the file for write,=20
which would make things just work. Note I'd suggest that if you add this,=
=20
it be an option that is off by default. I think for real tape drives, you=
=20
want O_RDONLY.

Take care,

Bill

--UoPmpPX/dBe4BELn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAyLWaWz+3JHUci9cRApyPAJ4+A3Vgwt2TFaM6N7tOxybC7Y1MkQCeOTGG
eGGa4/oXta8giHoCnGhkFnE=
=/dQW
-----END PGP SIGNATURE-----

--UoPmpPX/dBe4BELn--