DragonFlyBSD

I've identified the issue. In devfs getattr vnop I'm doing:
vap->va_bytes = vap->va_size = sizeof(struct devfs_node);
and kern_lseek then does:
new_offset = offset + vattr.va_size;

I'm not quite sure how to solve this. Should the size be set to the physical
size if the device is a disk type? This would also result in fstat to return
the physical size for a disk.

Unless anyone considers it to always set va_size and st_size to the disk size
for a disk-type device in the next few hours or so, I'll do it this way.

Cheers,
Alex Hornung

oops; I meant "unless anyone considers it to be incorrect to always set
va_size..."

For reference:
http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
So the standard does not specify what st_size has to be for devices.

Any opinion on this matter?

Cheers,
Alex Hornung

On Thu, 17 Dec 2009 14:08:49 +0000
"Alex Hornung \(via DragonFly issue tracker\)"
<bugs@crater.dragonflybsd.org> wrote:

>
> Alex Hornung <ahornung@gmail.com> added the comment:
>
> I've identified the issue. In devfs getattr vnop I'm doing:
> vap->va_bytes = vap->va_size = sizeof(struct devfs_node);
> and kern_lseek then does:
> new_offset = offset + vattr.va_size;
>
> I'm not quite sure how to solve this. Should the size be set to the
> physical size if the device is a disk type? This would also result in
> fstat to return the physical size for a disk.

The one place I know it is used is in ddrescue where it is
expected to return the amount of data that will be read by reading the
device until EOF, which for a DVD would be the amount of data written on
the media but for a hard disk would be the physical size of the disk.

Alex Hornung (via DragonFly issue tracker) wrote:
> Alex Hornung <ahornung@gmail.com> added the comment:
>
> For reference:
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html
> So the standard does not specify what st_size has to be for devices.
>
> Any opinion on this matter?

If we have the size of the device in question (i.e. disk), it won't hurt to set it. Else maybe set 0 to avoid confusion? Alternatively seek to EOF could fail.

cheers
simon

Fixed in commit 2d0767552b6288b28a2ec45d633cfd93fa58ca64.
Steve, just fyi: you need to change your %ld formatter to %lld, as off_t is 64
bit wide.
I've tested this with several hard disks and partitions and a DVD. It seems to
work, but I'll wait for Steve's feedback before closing this issue.

Cheers,
Alex Hornung

On Thu, 17 Dec 2009 15:36:28 +0000
"Alex Hornung \(via DragonFly issue tracker\)"
<bugs@crater.dragonflybsd.org> wrote:

> Fixed in commit 2d0767552b6288b28a2ec45d633cfd93fa58ca64.

Works like a charm - Thank you very much.

> Steve, just fyi: you need to change your %ld formatter to %lld, as off_t
> is 64 bit wide.

Yeah I know - it was just a quick lash up to find out why ddrescue
was misbehaving, I'll be deleting it now.

> I've tested this with several hard disks and partitions and a DVD. It
> seems to work, but I'll wait for Steve's feedback before closing this
> issue.

Go ahead and close it.

:I've identified the issue. In devfs getattr vnop I'm doing:
:vap->va_bytes =3D vap->va_size =3D sizeof(struct devfs_node);
:and kern_lseek then does:
:new_offset =3D offset + vattr.va_size;
:
:I'm not quite sure how to solve this. Should the size be set to the physica=
:l=20
:size if the device is a disk type? This would also result in fstat to retur=
:n=20
:the physical size for a disk.
:
:Unless anyone considers it to always set va_size and st_size to the disk si=
:ze=20
:for a disk-type device in the next few hours or so, I'll do it this way.
:
:Cheers,
:Alex Hornung

BSDs in the past have not supported st_size on disk devices, but
linux has.

I personally think that if we can easily support st_size for disk devices
that we should.

-Matt

I don't think va_size should ever be set to the size of an internal
structure. That information is not meaningful to consumers / stat.
It should either be something meaningful, like the size of the
disk (partition/slice/etc) or 0.

For softlinks va_size is the length of the softlink string.

-Matt
Matthew Dillon
<dillon@backplane.com>

Note that %lld is 128 bits on 64-bit machines. The best thing to do is
to cast to size_t or ssize_t:

"... %ju ...", ... (size_t)blah
"... %jd ...", ... (ssize_t)blah

-Matt
Matthew Dillon
<dillon@backplane.com>

Ugh. never mind. long long is 64 bits. But use size_t anyway.

-Matt
Matthew Dillon
<dillon@backplane.com>