Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

I just now successfully copied 38G (second data set) to the same HDD via USB (after it has passed extended SMART), both with UFS2 and FAT32 fs (6 CAM write errors in the second case, but as far as I can see, data is ok). I think I hit something unrelated above, and as I've said, cannot

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

To sum up, looks like I cannot replicate original problem (corruption) with the USB dual card reader any more, and the HDD via USB thing is something different (maybe hardware related as it's exactly the same with UFS/FAT). -- View this message in context:

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

OK, I just have successfully wrote both problematic cards in the same USB card reader/port as the USB HDD above, using the same data set. The only CAM errors were at the same time as cards have run out of space. Now testing cping between them, but as they are on the same dual card reader/USB

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Wed, Feb 01, 2017 at 07:16:28AM -0700, Jakub Lach wrote: > I'm not sure if it's the same thing. Most of the times the corruption was > silent > then. > > Nonetheless, the outcome was the same after newfs HDD with UFS2- > > http://www.pastebin.ca/3762661 > > I would 'blame' USB now, if only

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Wed, Feb 01, 2017 at 07:25:18AM -0700, Jakub Lach wrote: > I would think so, if only I would not clone the disk/system via the same USB > port mere weeks ago. > Moreover, sysutils/f3 fully writes and validates (checksums) 30G+ memory > cards via the same port without problems. In my case

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

I would think so, if only I would not clone the disk/system via the same USB port mere weeks ago. Moreover, sysutils/f3 fully writes and validates (checksums) 30G+ memory cards via the same port without problems. -- View this message in context:

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Wed, Feb 01, 2017 at 06:52:01AM -0700, Jakub Lach wrote: > Yes, HDD and card reader was USB mounted. > > This time, I've copied about 12G from 38G from internal SSD (UFS2) to > HDD via USB (FAT32), then system panicked with CAM errors. I am have like issuse on laptop w/ broken USB

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

I'm not sure if it's the same thing. Most of the times the corruption was silent then. Nonetheless, the outcome was the same after newfs HDD with UFS2- http://www.pastebin.ca/3762661 I would 'blame' USB now, if only I did not migrate/clone the whole system to SSD via dump/the same USB not very

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

Yes, HDD and card reader was USB mounted. This time, I've copied about 12G from 38G from internal SSD (UFS2) to HDD via USB (FAT32), then system panicked with CAM errors. http://pastebin.ca/3762654 Apart from that, there are no corrupted files in the way there were with card reader. I will

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Wed, Feb 01, 2017 at 06:02:45AM -0700, Jakub Lach wrote: > Yes, it has happened also with another device. Which was not a card reader > (HDD > mounted by USB), and I have used the same card reader configuration to copy > the memory card content with iMac. Is your card reader USB-attached,

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

Moreover, sysutils/f3 was reading and writing with this memory card configuration fine. Which is why I don't _blame_ fs, I only know that FAT + cp -r consistently gave me problems, for one reason or another. -- View this message in context:

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

Yes, it has happened also with another device. Which was not a card reader (HDD mounted by USB), and I have used the same card reader configuration to copy the memory card content with iMac. -- View this message in context:

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Wed, Feb 01, 2017 at 05:38:07AM -0700, Jakub Lach wrote: > As it shows your interest, I appreciate your answer very much. > > I was a bit let down then, I had to (using the same card reader), > cp -r using borrowed Apple iMac. It worked as it should. > > It was FreeBSD 11.0-STABLE #0 r310265

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

As it shows your interest, I appreciate your answer very much. I was a bit let down then, I had to (using the same card reader), cp -r using borrowed Apple iMac. It worked as it should. It was FreeBSD 11.0-STABLE #0 r310265 amd64 as in subject, I will reconsider retesting now and filling a PR,

Re: FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

On Thu, 29 Dec 2016 20:06:31 +0100, Jakub Lach wrote: Hello, I've recently tried to make a switch to a bigger memory card in some device; what I've discovered, is that FreeBSD is cp-ing garbage to a mounted FAT32 fs after first 10-20 GB (depending on luck). What I

FreeBSD 11.0-STABLE #0 r310265 amd64 seems to be cpi-ing garbage to mounted FAT32 fs after 10-20 GB.

Hello, I've recently tried to make a switch to a bigger memory card in some device; what I've discovered, is that FreeBSD is cp-ing garbage to a mounted FAT32 fs after first 10-20 GB (depending on luck). What I mean by garbage are non removable 'files' with random names which cannot be