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 gue
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, dr
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 th
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 caus
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 fo
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 th
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 transpor
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 q
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
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 time
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 wa
11 matches
Mail list logo
