On Wed, Jun 17, 2015 at 8:33 AM, Christian <cdys...@gmail.com> wrote: > On 06/17/2015 10:22 AM, Chris Murphy wrote: >> >> On Wed, Jun 17, 2015 at 6:56 AM, Christian Dysthe <cdys...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> Sorry for asking more about this. I'm not a developer but trying to >>> learn. >>> In my case I get several errors like this one: >>> >>> root 2625 inode 353819 errors 400, nbytes wrong >>> >>> Is it inode 353819 I should focus on and what is the number after "root", >>> in >>> this case 2625? >> >> >> I'm going to guess it's tree root 2625, which is the same thing as fs >> tree, which is the same thing as subvolume. Each subvolume has its own >> inodes. So on a given Btrfs volume, an inode number can exist more >> than once, but in separate subvolumes. When you use btrfs inspect >> inode it will list all files with that inode number, but only the one >> in subvol ID 2625 is what you care about deleting and replacing. >> > Thanks! Deleting the file for that inode took care of it. No more errors. > Restored it from a backup. > > However, fstrim still gives me "0 B (0 bytes) trimmed, so that may be > another problem. Is there a way to check if trim works?
That sounds like maybe your SSD is blacklisted for trim, is all I can think of. So trim shouldn't be the cause of the problem if it's being blacklisted. The recent problems appear to be around newer SSDs that support queue trim and newer kernels that issue queued trim. There have been some patches related to trim to the kernel, but the existence of blacklisting and claims of bugs in firmware make it difficult to test and isolate. http://techreport.com/news/28473/some-samsung-ssds-may-suffer-from-a-buggy-trim-implementation -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
