Atsushi Abe
Atsushi Abe
I think the drive list logic of the `cam` tape backend has a problem. But you already know the device file of the drive. I think you can try `ltfs...
Close this because we don't have any activity 1 year. Please feel free to open if you have new findings.
Hi, Could you try `-o direct_io` option of the command `ltfs` when you mount the LTFS ? Like ``` ltfs -o devname=[drive_serial] -o tape_backend=sg -o sync_type=unmount -o direct_io /mnt ```...
It's interesting. In my experience in RHEL7 and IBM's LTO Full Height drives. The multi-thread copy architecture never helps the improvement of performance before because FUSE and the drive do...
I think it is good to implement a copy logic with a writer thread and a reader thread in the future.
The 4 warnings are expected at this time. These are unchecked in the compilers on RHEL7/8. Need to improve in the future.
> BTW, if "-W and -Wall" are added to OPT_FLAGS= , it generates a lot of warnings(929) Hmm, it is little bit strange to me. In RHEL7/8, `-W and -Wall`...
Thank you for your info. I just have took a look them. My understanding sgv3 I/F is still supported. Is it correct? Anyway I will add the switch to select...
Interesting. It looks LTFS receives `early warning` at writing the first FM of an index. And this HP drive returns `end-of-medium` just after 50 writes when `early warning` is reported....
Thank you for your addition info. It looks reporting timing of `early warning` on the HP's LTO5 is too late. We need to have 500MiB at least... On IBM tape...