Andriy Gapon wrote:
on 26/02/2008 21:23 Pav Lucistnik said the following:
Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100:
Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
Yay, and can you fix the sequential read performance while you're at it?
Kthx!
this was almost trivial :-)
See the
Pav Lucistnik wrote:
Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
And while I have your attention, I have a related question.
I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
mkisofs, and when I mount the UDF part of them, the mount point (root
directory of media) have 0
on 28/02/2008 11:59 Pav Lucistnik said the following:
> Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
>
> And while I have your attention, I have a related question.
>
> I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
> mkisofs, and when I mount the UDF part of them, the m
Andriy Gapon píše v čt 28. 02. 2008 v 10:33 +0200:
And while I have your attention, I have a related question.
I have produced a bunch of ISO9660 Level 3 / UDF hybrid media with
mkisofs, and when I mount the UDF part of them, the mount point (root
directory of media) have 0x000 permissions. Yes t
on 26/02/2008 21:23 Pav Lucistnik said the following:
> Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100:
>> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>>
Yay, and can you fix the sequential read performance while you're at it?
Kthx!
>>> this was almost trivial :-)
>>> See the a
Pav Lucistnik píše v út 05. 02. 2008 v 19:16 +0100:
> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>
> > > Yay, and can you fix the sequential read performance while you're at it?
> > > Kthx!
>
> > this was almost trivial :-)
> > See the attached patch, first hunk is just for consistency.
>
On Tue, 12 Feb 2008, Andriy Gapon wrote:
on 12/02/2008 15:11 Bruce Evans said the following:
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
3.1. for a fresh buf getlbk would assign the following:
bsize = bo->bo_bsize;
offset = blkno * bsi
on 12/02/2008 17:58 Bruce Evans said the following:
> On Tue, 12 Feb 2008, Andriy Gapon wrote:
>> And the actual reading works correctly because udf_strategy is called
>> for such vnodes and it translates block numbers from physical to logical
>> and also correctly re-calculates b_iooffset for actu
on 12/02/2008 15:11 Bruce Evans said the following:
> On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
>
>> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>>
>>> 2.3. this code passes to bread blkno that is calculated as 4*sector,
>>> where sector is a number of a physical 2048-byte sector. [**
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
2.3. this code passes to bread blkno that is calculated as 4*sector,
where sector is a number of a physical 2048-byte sector. [**]
[**] - I think that this is a requirement of buffcache system, b
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
on 06/02/2008 18:29 Andriy Gapon said the following:
Small summary of the above long description.
For directory reading fs/udf performs bread() on a (underlying) device
vnode. It passes block num
on 12/02/2008 13:47 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>
>> 2.3. this code passes to bread blkno that is calculated as 4*sector,
>> where sector is a number of a physical 2048-byte sector. [**]
>> [**] - I think that this is a requirement o
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>2.3. this code passes to bread blkno that is calculated as 4*sector,
>where sector is a number of a physical 2048-byte sector. [**]
>[**] - I think that this is a requirement of buffcache system, because
>internally it performs many calculation
on 12/02/2008 10:53 Poul-Henning Kamp said the following:
> In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>> on 06/02/2008 18:29 Andriy Gapon said the following:
>>> Small summary of the above long description.
>>> For directory reading fs/udf performs bread() on a (underlying) device
>>> vn
In message <[EMAIL PROTECTED]>, Andriy Gapon writes:
>on 06/02/2008 18:29 Andriy Gapon said the following:
>> Small summary of the above long description.
>> For directory reading fs/udf performs bread() on a (underlying) device
>> vnode. It passes block number as if block size was 512 bytes (i.e.
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other hand vm page
on 06/02/2008 18:29 Andriy Gapon said the following:
> Small summary of the above long description.
> For directory reading fs/udf performs bread() on a (underlying) device
> vnode. It passes block number as if block size was 512 bytes (i.e.
> byte_offset_within_dev/512). On the other hand vm page
on 06/02/2008 18:34 Andriy Gapon said the following:
>
> Actually the patch is not entirely correct. max_size returned from
> udf_bmap_internal should be used to calculate number of continuous
> sectors for read-ahead (as opposed to file size in the patch).
>
Attached is an updated patch.
The m
on 05/02/2008 22:43 Scott Long said the following:
> Andriy Gapon wrote:
>
>> But there is another issue that I also mentioned in the email about
>> directory reading. It is UDF_INVALID_BMAP case of udf_bmap_internal,
>> i.e. the case when file data is embedded into a file entry.
>> This is a spec
on 05/02/2008 20:16 Pav Lucistnik said the following:
> Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
>
>>> Yay, and can you fix the sequential read performance while you're at it?
>>> Kthx!
>
>> this was almost trivial :-)
>> See the attached patch, first hunk is just for consistency.
>> Th
on 04/02/2008 17:55 Scott Long said the following:
> Andriy Gapon wrote:
[snip]
>> After some code reading and run-time debugging, here are some facts
>> about udf directory reading:
>> 1. bread-ing is done via device vnode (as opposed to directory vnodes),
>> as a consequence udf_strategy is not i
Andriy Gapon wrote:
on 04/02/2008 22:07 Pav Lucistnik said the following:
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file s
Andriy Gapon wrote:
on 04/02/2008 22:07 Pav Lucistnik said the following:
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file s
Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200:
> > Yay, and can you fix the sequential read performance while you're at it?
> > Kthx!
> this was almost trivial :-)
> See the attached patch, first hunk is just for consistency.
> The code was borrowed from cd9660, only field/variable names are
on 04/02/2008 20:36 Julian Elischer said the following:
> Andriy Gapon wrote:
>> More on the problem with reading big directories on UDF.
>
> You do realise that you have now made yourself the official
> maintainer of the UDF file system by submitting a competent
> and insightful analysis of the p
on 04/02/2008 22:07 Pav Lucistnik said the following:
> Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
>> Andriy Gapon wrote:
>>> More on the problem with reading big directories on UDF.
>> You do realise that you have now made yourself the official
>> maintainer of the UDF file system by su
Julian Elischer píše v po 04. 02. 2008 v 10:36 -0800:
> Andriy Gapon wrote:
> > More on the problem with reading big directories on UDF.
>
> You do realise that you have now made yourself the official
> maintainer of the UDF file system by submitting a competent
> and insightful analysis of the pr
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
You do realise that you have now made yourself the official
maintainer of the UDF file system by submitting a competent
and insightful analysis of the problem?
First, some sleuthing. I came to believe that the probl
Andriy Gapon wrote:
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
for
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
for devices have non-NUL
More on the problem with reading big directories on UDF.
First, some sleuthing. I came to believe that the problem is caused by
some larger change in vfs/vm/buf area. It seems that now VMIO is applied
to more vnode types than before. In particular it seems that now vnodes
for devices have non-NUL
31 matches
Mail list logo
