Hello. I''ve been running Ubuntu 12.04 kernel and btrfs on two partitions of two GPT partitioned SSDs. Rootfs was btrfs subvol "@" and homes were at "@home". When I was batch trimming with "fstrim /" using Ubuntu''s standard kernel 3.2.0 - everything was fine. Then I compiled vanilla 3.3.6 kernel ad tried to fstrim again, fs got severely damaged. It seems that batch trim miscalculates ranges and trims some occupied space. Can''t say if GPT or other partitioning details matter. I will try to provide any info possible, but fs is trimmed badly, and I need this machine to be up and running, so will have to mkfs.btrfs again and use 3.2.0 kernel. Steps that caused corruption: 1. Created partitions on two (say /dev/sd[ab]) SSD drives with about 1G offset from the beginning (first partition is ext4 for /boot) 2. mkfs.btrfs /dev/sd[ab]2 3. created subvolumes "@" and "@home" for mountpoints "/" and "/home" respectively 4. installed xubuntu 12.04 5. fstrim / 6. everything is ok 7. compiled and installed vanilla 3.3.6 kernel 8. reboot into 3.3.6 9. btrfs scrub - ok 10. fstrim / 11. fs got baaadly corrupted -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 17, 2012 at 08:10:20PM +0400, Sergey E. Kolesnikov wrote:> Hello. > I''ve been running Ubuntu 12.04 kernel and btrfs on two partitions of > two GPT partitioned SSDs. Rootfs was btrfs subvol "@" and homes were > at "@home". When I was batch trimming with "fstrim /" using Ubuntu''s > standard kernel 3.2.0 - everything was fine. Then I compiled vanilla > 3.3.6 kernel ad tried to fstrim again, fs got severely damaged. > > It seems that batch trim miscalculates ranges and trims some > occupied space. Can''t say if GPT or other partitioning details > matter.The issue was apparently fixed in 3.4-rc2: http://lkml.indiana.edu/hypermail/linux/kernel/1204.1/00340.html -- Tomasz Torcz To co nierealne -- tutaj jest normalne. xmpp: zdzichubg@chrome.pl Ziomale na życie mają tu patenty specjalne. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/18/2012 12:10 AM, Sergey E. Kolesnikov wrote:> Hello. > I''ve been running Ubuntu 12.04 kernel and btrfs on two partitions of two > GPT partitioned SSDs. Rootfs was btrfs subvol "@" and homes were at > "@home". When I was batch trimming with "fstrim /" using Ubuntu''s > standard kernel 3.2.0 - everything was fine. Then I compiled vanilla > 3.3.6 kernel ad tried to fstrim again, fs got severely damaged. > > It seems that batch trim miscalculates ranges and trims some occupied > space. Can''t say if GPT or other partitioning details matter. > > I will try to provide any info possible, but fs is trimmed badly, and I > need this machine to be up and running, so will have to mkfs.btrfs again > and use 3.2.0 kernel. > > Steps that caused corruption: > 1. Created partitions on two (say /dev/sd[ab]) SSD drives with about 1G > offset from the beginning (first partition is ext4 for /boot) > 2. mkfs.btrfs /dev/sd[ab]2 > 3. created subvolumes "@" and "@home" for mountpoints "/" and "/home" > respectively > 4. installed xubuntu 12.04 > 5. fstrim / > 6. everything is ok > 7. compiled and installed vanilla 3.3.6 kernel > 8. reboot into 3.3.6 > 9. btrfs scrub - ok > 10. fstrim / > 11. fs got baaadly corruptedCould you please show some logs about the corrpution? I''ll try to reproduce it on my own box. ;) thanks, liubo> -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. 2012/5/18 Liu Bo <liubo2009@cn.fujitsu.com>> > On 05/18/2012 12:10 AM, Sergey E. Kolesnikov wrote: > Could you please show some logs about the corrpution?Ugh. Sorry, but logs got corrupted too :-( Today I''ve tested 3.4-rc7 kernel and everything seems to be fine. May be fix mentioned by Tomasz should be ported back to 3.3.x since it is current stable release and this bug is really dangerous. Thanks, Sergey. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html