[clug] ntfs-3g anyone?

[Eyal Lebedinsky]

After trying a few things as I posted about, and finding that the latest ntfs-3g
works well, I decided to re-run the checksums using the old (native to f19) ntfs-3g
to confirm that this really was the problem. It did not fail this time. I tried
three times more with clean results.

I now do not know what caused the original problem. It was very unusual, and I am
now worried about using the disk. However, since I do validate it with checksums
each time I can assume that a clean run can be trusted.

I wonder if attaching the disk to windows quietly fixed something.

I should add that initially I wrote to the disk on linux, and got millions of ntfs
errors, and was unable to complete the data transfer. I then moved it to windows
where I clean formatted it and copied the files off a samba share. I then connected
it to linux to get the checksums and where I started seeing the inconsistent read
failures. It is this last process that I posted about, assuming that it has nothing
to do with the earlier trouble.

However, is it possible that some data was left hanging around from the earlier time,
where ntfs was unable to properly close the volume (it was probably removed dirty).
And could linux have used this stale data against the newly formatted and filled disk?
I can see that no bad data was written to the disk though, I just wonder if there was
a cache issue.

I will keep a closer eye on it now.

cheers

On 21/06/16 18:42, Eyal Lebedinsky wrote:
> I am having issues with a 2.5" USB disk.
>
> 1)
> on fedora 19 I get these log messages when mounting the fs
>     ntfs-3g[13859]: Version 2013.1.13 integrated FUSE 27
>     ntfs-3g[13859]: Mounted /dev/sdj1 (Read-Write, label "Seagate-4TB", NTFS 3.1)
>     ntfs-3g[13859]: Cmdline options: rw,nodev,nosuid,uid=500,gid=500,dmask=0077,fmask=0177,uhelper=udisks2
>     ntfs-3g[13859]: Mount options: rw,nodev,nosuid,uhelper=udisks2,allow_other,nonempty,relatime,default_permissions,fsname=/dev/sdj1,blkdev,blksize=4096
>     ntfs-3g[13859]: Global ownership and permissions enforced, configuration type 1
> The mount is now accessible.
>
> On f22 I get
>     ntfs-3g[29109]: Version 2016.2.22 integrated FUSE 27
>     ntfs-3g[29109]: Mounted /dev/sdm1 (Read-Write, label "Seagate-4TB", NTFS 3.1)
>     ntfs-3g[29109]: Cmdline options: rw,nosuid,nodev,noexec,uid=0,gid=0,umask=077,fmask=0177,dmask=0077,user
>     ntfs-3g[29109]: Mount options: rw,nosuid,nodev,noexec,user,allow_other,nonempty,relatime,default_permissions,fsname=/dev/sdm1,blkdev,blksize=4096
>     ntfs-3g[29109]: Global ownership and permissions enforced, configuration type 1
> The mount point is not accessible, what I get is
>     $ ls -l /run/media/eyal/
>     ls: cannot access /run/media/eyal/Seagate-4TB: Transport endpoint is not connected
>     total 0
>     d????????? ? ? ? ?            ? Seagate-4TB
>
> If I mount manually
>     $ sudo ntfs-3g /dev/sdm1 /usb
> I see
>     ntfs-3g[29335]: Version 2016.2.22 integrated FUSE 27
>     ntfs-3g[29335]: Mounted /dev/sdm1 (Read-Write, label "Seagate-4TB", NTFS 3.1)
>     ntfs-3g[29335]: Cmdline options:
>     ntfs-3g[29335]: Mount options: allow_other,nonempty,relatime,fsname=/dev/sdm1,blkdev,blksize=4096
>     ntfs-3g[29335]: Ownership and permissions disabled, configuration type 1
>     ntfs-3g[29335]: Unmounting /dev/sdm1 (Seagate-4TB)
> The last line looks unexpected to me. Inspecting the mount fails:
>     $ ls -l /usb
>     ls: cannot access /usb: Transport endpoint is not connected
> Interestingly, no messages are logged with the following
>     $ sudo umount /usb
>     $ sudo umount /usb
>     umount: /usb: not mounted
>
> I searched and found no solution. Anyone using ntfs-3g?
>
> 2)
> Another issue, may be related, is that on f19 (where the mount is visible) I get bad data regularly.
> This is a new 4TB disk which I want to use for archival storage. Naturally I run checksum on the
> files and I am getting many files delivering bad checksums. Re-running fails a different set of files.
>
> There are no errors logged that I could find.
>
> I should mention that this disk was formatted and written to on Windows 8.1, and as such I expect the
> data on it to be in good shape. Furthermore, a failed checksum will come good next time I try the same
> file.
>
> TIA
>
> --
> Eyal Lebedinsky (eyal at eyal.emu.id.au)
>

-- 
Eyal Lebedinsky (eyal at eyal.emu.id.au)