I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512 sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mounted
The second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
Have you ever had this card work in anything?
And if you have used this card for a long time how long have you used it for ?
And where did you purchase the card from and when, and how much did it cost?
On Tue, Aug 8, 2023 at 11:43 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512 sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mountedThe second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
If it has never worked anyplace then read through this: https://photographylife.com/fake-memory-cards
On Tue, Aug 8, 2023 at 12:33 PM Roger Heflin rogerheflin@gmail.com wrote:
Have you ever had this card work in anything?
And if you have used this card for a long time how long have you used it for ?
And where did you purchase the card from and when, and how much did it cost?
On Tue, Aug 8, 2023 at 11:43 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512 sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mountedThe second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
As far as I can tell, my SanDisk Ultra card is genuine. The article is very useful to the uninitiated. Thanks.
On Tue, 8 Aug 2023 12:41:55 -0500 Roger Heflin rogerheflin@gmail.com wrote:
If it has never worked anyplace then read through this: https://photographylife.com/fake-memory-cards
On Tue, Aug 8, 2023 at 12:33 PM Roger Heflin rogerheflin@gmail.com wrote:
Have you ever had this card work in anything?
And if you have used this card for a long time how long have you used it for ?
And where did you purchase the card from and when, and how much did it cost?
On Tue, Aug 8, 2023 at 11:43 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mounted
The second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote: > > I have a 1TB SanDisk XC SD card, which has developed a > reluctance to create files. > > UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC > ext4 noauto,rw,user 0 0 > > % sudo mount /Media/SDXC > % touch /Media/SDXC/foo > % ls /Media/SDXC/foo > /Media/SDXC/foo > % sudo umount /Media/SDXC > % sudo mount /Media/SDXC > % ls /Media/SDXC/foo > /bin/ls: cannot access '/Media/SDXC/foo': No such file or > directory > > I used root to mount, just to be sure. User mount has the > same problem. gparted reported a problem with the > superblock which was resolved by re-formatting and > re-creating the partition table. The card has just one > partition. > > Suggestions for further diagnosis would be appreciated.
you are welcome. last guy with a problem with one had spent $25 for his 2TB card. Found out that it was internally a 16GB card appearing as a 2TB card.
I am guessing the card has very limited(maybe no) wear leveling which means that any blocks written a lot will burn out.
So you can see if partitioning will leave you with something that works, but that may only let it work a while longer before another block wears out.
Since a write would normally reallocate/replace the data to a good sector and map the bad sector out then I would suspect there is no bad/burned block management code so probably no wear leveling either.
it is probably best to get a new one. From my understanding most of the USB and sd*c cards often have no block management/wear leveling and eventually will do this (there may be some that have it, but who knows).
SO given that a 1tb usb/mmc/sdxc card is not the same thing as a real ssd that has decent wear leveling.
On Tue, Aug 8, 2023 at 2:55 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
As far as I can tell, my SanDisk Ultra card is genuine. The article is very useful to the uninitiated. Thanks.
On Tue, 8 Aug 2023 12:41:55 -0500 Roger Heflin rogerheflin@gmail.com wrote:
If it has never worked anyplace then read through this: https://photographylife.com/fake-memory-cards
On Tue, Aug 8, 2023 at 12:33 PM Roger Heflin rogerheflin@gmail.com wrote:
Have you ever had this card work in anything?
And if you have used this card for a long time how long have you used it for ?
And where did you purchase the card from and when, and how much did it cost?
On Tue, Aug 8, 2023 at 11:43 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mounted
The second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
> What does it show in messages after the mount? That is > where I would expect the underlying read errors to be. > > I have also had some issues with certain sdxc readers > seeming to not work well with some cards. There are also a > significant number of MMC changes going into the kernel > recently. There is an entire new set of code (not sure if > has made it into the latest released kernel yet) for the > UHS-II cards (All UHS-II cards are working backwards compat > for UHS-I). > > You might try a different machine/reader and see if it > works on a different one. The issues I saw only happened > with the larger and/or faster cards and only in some > readers. > > On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach > geoffleach.gl@gmail.com wrote: > > > > I have a 1TB SanDisk XC SD card, which has developed a > > reluctance to create files. > > > > UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC > > ext4 noauto,rw,user 0 0 > > > > % sudo mount /Media/SDXC > > % touch /Media/SDXC/foo > > % ls /Media/SDXC/foo > > /Media/SDXC/foo > > % sudo umount /Media/SDXC > > % sudo mount /Media/SDXC > > % ls /Media/SDXC/foo > > /bin/ls: cannot access '/Media/SDXC/foo': No such file or > > directory > > > > I used root to mount, just to be sure. User mount has the > > same problem. gparted reported a problem with the > > superblock which was resolved by re-formatting and > > re-creating the partition table. The card has just one > > partition. > > > > Suggestions for further diagnosis would be appreciated.
Yes, the card has been in use for nearly two years and has 250G of data. The problem only began recently.
It was purchased on Amazon for $110 +/- a couple of years ago.
On Tue, 8 Aug 2023 12:33:13 -0500 Roger Heflin rogerheflin@gmail.com wrote:
Have you ever had this card work in anything?
And if you have used this card for a long time how long have you used it for ?
And where did you purchase the card from and when, and how much did it cost?
On Tue, Aug 8, 2023 at 11:43 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
dmesg says [ +41.509460] EXT4-fs (mmcblk0p1): recovery complete [ +0.001206] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [Aug 7 20:36] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c. [ +5.667580] EXT4-fs (mmcblk0p1): recovery complete [ +0.001092] EXT4-fs (mmcblk0p1): mounted filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c r/w with ordered data mode. Quota mode: none. [ +12.728248] EXT4-fs (mmcblk0p1): unmounting filesystem 0fd984c4-cf88-408a-8ba5-15b64500bd5c.
The two systems are intel-based laptops running up-to-date Fedora 37. The original problem system is a CLEVO W150HRM
*-device description: SD Card product: SD01T vendor: SanDisk physical id: aaaa logical name: /dev/mmcblk0 version: 8.5 date: 07/2022 serial: 3601907256 size: 953GiB (1023GB) capabilities: sd partitioned partitioned:dos configuration: logicalsectorsize=512sectorsize=512 signature=09ca262d *-volume description: EXT4 volume vendor: Linux physical id: 1 logical name: /dev/mmcblk0p1 logical name: /Media/SDXC version: 1.0 serial: 0fd984c4-cf88-408a-8ba5-15b64500bd5c size: 953GiB capacity: 953GiB capabilities: primary journaled extended_attributes large_files huge_files dir_nlink recover extents ext4 ext2 initialized configuration: created=2022-09-10 21:14:20 filesystem=ext4 label=MP4 lastmountpoint=/Media/SDXC modified=2022-10-07 08:25:42 mount.fstype=ext4 mount.options=rw,nosuid,nodev,noexec,relatime mounted=2022-10-07 08:25:42 state=mounted
The second system is a StarLabs StarLab mk III Aside from more memory, SD main storage, more recent Intel CPU ... not much different :-) Despite all of that, the problem with the SD is the same.
On Mon, 7 Aug 2023 18:23:12 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What is in messages? The sorts of errors you are getting indicate that the card is simply not working at all for some reason on linux.
And how different were the 2 systems that you tried it on?
I have a nice 256G UHS-II card that works fine in my camera, but in the laptop with the fastest mmc reader it will get a hard read error that shows in dmesg/messages that prevents it from working at any level.
You need the errors coming out of the kernel. Running commands from userspace against the card won't tell you anything about what the kernel itself thinks is wrong.
On Mon, Aug 7, 2023 at 5:52 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Thanks for the reply.
The SD card behaves the same way on another system (F37)
In desperation, I removed all of the date and used gparted to delete and recreate the file system. It did than, then restored all of the deleted files.
I have the new result below. It appears that I need to replace the superblock, but I've been unable to discover how to do that.
# e2fsck /dev/mmcblk0p1 e2fsck 1.46.5 (30-Dec-2021) MP4: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? yes e2fsck: unable to set superblock flags on MP4 MP4: ********** WARNING: Filesystem still has errors **********
On Mon, 7 Aug 2023 11:05:17 -0500 Roger Heflin rogerheflin@gmail.com wrote:
What does it show in messages after the mount? That is where I would expect the underlying read errors to be.
I have also had some issues with certain sdxc readers seeming to not work well with some cards. There are also a significant number of MMC changes going into the kernel recently. There is an entire new set of code (not sure if has made it into the latest released kernel yet) for the UHS-II cards (All UHS-II cards are working backwards compat for UHS-I).
You might try a different machine/reader and see if it works on a different one. The issues I saw only happened with the larger and/or faster cards and only in some readers.
On Mon, Aug 7, 2023 at 10:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
On Tue, Aug 8, 2023 at 3:30 PM Geoffrey Leach geoffleach.gl@gmail.com wrote:
Yes, the card has been in use for nearly two years and has 250G of data. The problem only began recently.
It was purchased on Amazon for $110 +/- a couple of years ago.
Shot in the dark things to try....
First, save the data somewhere else, then: - re-partition the card with 2 partitions instead of 1, and then re-do mkfs on each partition. Or don't use any partitions. Or just change the start block. - re-do mkfs but use xfs instead - determine the bad superblock location and use dd to overwrite with zeros - use dd to zero the entire partition
Basically anything that would move or destroy the problematic superblock ( this is assuming the superblock is actually the issue as opposed to something else, which may be a bad assumption).
On Tue, 2023-08-08 at 12:28 -0700, Geoffrey Leach wrote:
Yes, the card has been in use for nearly two years and has 250G of data. The problem only began recently.
I wouldn't trust the card, then. If the card has gone bad, rather than the computer just messed up the data it puts on it, chances are it's just going to get worse and worse. If reformatting didn't help you, I'd say get rid of the card to do yourself a favour. Perhaps see if the card had a long warranty on it.
For what it's worth, I don't re-use SD cards. I've had bad experiences with re-used cards, and with re-formatting then.
I used to use them with my camera, before I got a phone with a good camera. And I still use them with Zoom and Tascam sound recorders. But I just fill them up (though not to 100%), then store the full ones on the shelf as my back-up, and put a new card in the device. As someone who started off in photography with 35 mm film, the idea of "stashing the negatives for posterity" is still in my mindset.
Mind you, these aren't $100+ cards. They're store bought Sandiscs (and other brands I trust) costing around $40 for 64 gig, or less for 32 gig. Quite apart from the devices having size limits for the cards they support, I found that really huge cards meant far too many files to comfortably work with on speed-limited media or card readers.
On Wed, 09 Aug 2023 11:25:42 +0930 Tim via users users@lists.fedoraproject.org wrote:
On Tue, 2023-08-08 at 12:28 -0700, Geoffrey Leach wrote:
Yes, the card has been in use for nearly two years and has 250G of data. The problem only began recently.
I wouldn't trust the card, then. If the card has gone bad, rather than the computer just messed up the data it puts on it, chances are it's just going to get worse and worse. If reformatting didn't help you, I'd say get rid of the card to do yourself a favour. Perhaps see if the card had a long warranty on it.
For what it's worth, I don't re-use SD cards. I've had bad experiences with re-used cards, and with re-formatting then.
I used to use them with my camera, before I got a phone with a good camera. And I still use them with Zoom and Tascam sound recorders. But I just fill them up (though not to 100%), then store the full ones on the shelf as my back-up, and put a new card in the device. As someone who started off in photography with 35 mm film, the idea of "stashing the negatives for posterity" is still in my mindset.
Mind you, these aren't $100+ cards. They're store bought Sandiscs (and other brands I trust) costing around $40 for 64 gig, or less for 32 gig. Quite apart from the devices having size limits for the cards they support, I found that really huge cards meant far too many files to comfortably work with on speed-limited media or card readers.
Much as my pocketbook hates to admit it, good advice. Thanks.
On 8/8/23 09:43, Geoffrey Leach wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
You can't do that. The filesystem puts the superblock in a specific position. If the SD card has a bad block, then it's probably time to toss it. But you could try copying /dev/zero to the entire card and see if it reallocates.
On Tue, 8 Aug 2023 12:52:50 -0700 Samuel Sieb samuel@sieb.net wrote:
On 8/8/23 09:43, Geoffrey Leach wrote:
Answers to questions below. FWIW, on both systems a different SD card performs with no problem. That and the error message from e2fsck lead me to suspect that my problem is a bad superblock on the card. I've been unable to find any instructions on how to get e2fsck to mark the current superblock bad and create a new superblock.
You can't do that. The filesystem puts the superblock in a specific position. If the SD card has a bad block, then it's probably time to toss it. But you could try copying /dev/zero to the entire card and see if it reallocates.
Not good news, but helpful none the less. Thanks.
On 8/7/2023 10:18 AM, Geoffrey Leach wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
I used root to mount, just to be sure. User mount has the same problem. gparted reported a problem with the superblock which was resolved by re-formatting and re-creating the partition table. The card has just one partition.
Suggestions for further diagnosis would be appreciated.
Are you able to read existing files off the SD flash?
Did the "touch /Media/SDXC/foo" operation above fail due to Read-Only filesystem?
I do have a lot of experience with managed/unmanaged flash filesystems under Linux, but don't assume the following applies to your particular case. Higher-quality "Managed Flash" devices (like SD/uSD/MMC/eMMC) self-monitor their own "health status" over time. When the flash array begins to develop a sufficient number of bad sectors, many will mark themselves Read-Only to prevent loss of future data (but allow you the opportunity to off-load existing files before total failure occurs). Cheap-o units aren't as well-behaved- they just fail to retain new files. You might see some flash/disk related messages in the syslog during the "sync".
Does this problem occur with any other flash devices you have?
If this problem seems to affect only that single flash device, I would suggest permanently retiring it and moving to an alternate. <voice of experience here- make sure you clearly mark it "BAD!!" and throw it away, otherwise it WILL unexpectedly reappear in the future and provide the same entertaining learning-experience, again and again... ;) >
On Mon, Aug 7, 2023 at 11:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
Forgive my ignorance, but aren't you supposed to flush the drive before removing it? I would expect to see a sync in there somewhere. Like before the 'sudo umount /Media/SDXC'.
What does dmsg have to say about the card?
Jeff
On 8/8/23 10:17, Jeffrey Walton wrote:
On Mon, Aug 7, 2023 at 11:19 AM Geoffrey Leach geoffleach.gl@gmail.com wrote:
I have a 1TB SanDisk XC SD card, which has developed a reluctance to create files.
UUID=0fd984c4-cf88-408a-8ba5-15b64500bd5c /Media/SDXC ext4 noauto,rw,user 0 0
% sudo mount /Media/SDXC % touch /Media/SDXC/foo % ls /Media/SDXC/foo /Media/SDXC/foo % sudo umount /Media/SDXC % sudo mount /Media/SDXC % ls /Media/SDXC/foo /bin/ls: cannot access '/Media/SDXC/foo': No such file or directory
Forgive my ignorance, but aren't you supposed to flush the drive before removing it? I would expect to see a sync in there somewhere. Like before the 'sudo umount /Media/SDXC'.
unmounting automatically does a sync. That's why it can take a while before the umount program exits.
-
Geoffrey Leach -
Go Canes -
Jeffrey Walton -
Roger Heflin -
Ron Flory -
Samuel Sieb -
Tim