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 attached patch,
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
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 mount
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
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 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.
The code
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 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 *
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 actual
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. [**]
[**] - I
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,
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
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 of
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 calculations
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
vnode. It
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 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 involved
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.
The code was
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 special case
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 most
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 submitting
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
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
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
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
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
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
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
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
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 problem?
31 matches
Mail list logo
