Hi,
The reason to use O_DIRECT is to avoid impact on the performance of
other processes in the system, rather than to improve speed.
The odd point is that mmap() versus calloc()
influences SG_IO write speed.
The read performance from disk was sufficient
in all the tests. (fifo well filled,
Thomas Schmitt wrote:
Hi,
me:
Is there any way how after umounting of the
filesystem the content is still not up to date
for subsequent reading of the file ?
The image file got opened by growisofs via
open64(O_DIRECT|O_RDONLY).
Jens Jorgensen:
Well there's a scary thought. I
Thomas Schmitt wrote:
Hi,
me:
Such a message is rarely harmless.
Jens:
Well, that's what I thought, but Andy Polyakov commented here:
http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html
Oh indeed. Now i remember.
I stepped into that puddle previously.
So
Hi,
Jens Jorgensen:
Could it be that there was a defect and things were relocated?
me :
It should be transparent to the reader in any
case.
...
So this could be a failure of the firmware
to correctly perform Defect Management.
Rob Bogus:
Is it possible that this is caused by a
Hi,
me:
Is there any way how after umounting of the
filesystem the content is still not up to date
for subsequent reading of the file ?
The image file got opened by growisofs via
open64(O_DIRECT|O_RDONLY).
Jens Jorgensen:
Well there's a scary thought. I guess I would hope that opening
Thomas Schmitt wrote:
Hi,
/dev/sr1: flushing cache
/dev/sr1: closing track
/dev/sr1: closing session
:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output
Such a message is rarely harmless.
The drive wrote everything but failed
to finish properly.
Well,
Hi,
me:
Such a message is rarely harmless.
Jens:
Well, that's what I thought, but Andy Polyakov commented here:
http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html
Oh indeed. Now i remember.
I stepped into that puddle previously.
So for now we count it as harmless.
It is
Thomas Schmitt wrote:
When I read the block from /dev/sr0 what I get back is all-zeroes. The
corresponding block on the udf image is full of non-zero data.
the next 2048-byte block following 8585216 on /dev/sr1 is non-zero.
Ouchers.
That looks much like a failure of transport or
Hi,
So it certainly sees /some/ of the UDF info. Gack!
It would be quite some strange incident if a
zeroed block at a more or less random address
would make this all a valid empty UDF filesystem.
I am not sure whether the empty mount directory
is really caused by the altered block(s).
Maybe
So I decided I wanted to back up my Windows drive, which is NTFS. Since
there are very big files there, very deep directories, crazy filenames,
etc. I figure UDF is the way to go. The total size was 37GB. I've got a
Blu-Ray burner and so I figure I'll buy a BD-R DL disc and do it. Since
I didn't
Hi,
BD-R DL disc
mkudffs -r 0x0201 --vid=Old C --media-type=hd --utf8
/video/oldc_backup.udf 20971520
growisofs -Z /dev/sr1=/video/oldc_backup.udf
builtin_dd: 20971520*2KB out @ average 0.7x4390KBps
Looks like 2x BD speed with Defect Management
enabled. This makes really long run times.
But
11 matches
Mail list logo
