Am Montag, 9. April 2012 schrieb Daniel J Blueman: > On 9 April 2012 22:44, Leho Kraav <leho@xxxxxxxxx> wrote: > > On 09.04.2012 17:35, Daniel J Blueman wrote: > >> Leho Kraav<leho<at> kraav.com> writes: > >> [] > >> > >>> Apr 8 02:46:11 s9 kernel: [ 189.691778] attempt to access beyond > >>> end of device > >>> Apr 8 02:46:11 s9 kernel: [ 189.691787] dm-3: rw=129, > >>> want=23361976, limit=20967424 > >> > >> I recently bumped into this too [1]. Liu Bo posted a patch for it > >> [2], which tests out fine here. The workaround is to not mount with > >> 'discard' until eg ~3.4-rc3 or later. > >> > >> [1] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16409 > >> [2] http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16649 > > > > Oh wow, thanks. This sounds exactly like what happened. I got the > > livelock post off my search results, but the patch post doesn't seem > > to have any of the keywords I was looking for, since I had no idea > > it could be related to discards. > > > > So can this become a problem earlier too, not only when the space > > used is > > > approaching limits? If not, I think I should be good until 3.4: > Looks like it affects at least 3.3 and 3.4-rc1/2 in all circumstances. Is offline discard via fstrim also affected? I used fstrim some times for my / BTRFS with 3.3.0-trunk Debian kernel (should be 3.3.0) and martin@merkaba:~> zgrep "beyond" /var/log/syslog* martin@merkaba:~#1> Seems I am safe. But I think I won´t use fstrim for now anymore on any BTRFS partition until I have some confirmation that it is safe. Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
