Hi list, I''m a new BTRFS user and will try not to ask FAQs ;-) I''m currently using Btrfs v0.19 on stock Ubuntu Natty (kernel 2.6.38) and use a BTRFS inside an encrypted LVM. The wiki "gotchas" page https://btrfs.wiki.kernel.org/index.php/Gotchas states : « btrfs volumes on top of dm-crypt block devices (and possibly LVM) require write-caching to be turned off on the underlying HDD. Failing to do so, in the event of a power failure, may result in corruption not yet handled by btrfs code. (2.6.33) » ...So I''ve turned my write cache off, but I notice this is stated for kernel 2.6.33, so wonder if this still is an issue with 2.6.38, or has it been addressed since ? Thanks in advance for your help. Kind regards. -- 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 12, 2011 at 07:45:25AM +0200, Swâmi Petaramesh wrote:> Hi list, > > I''m a new BTRFS user and will try not to ask FAQs ;-) > > I''m currently using Btrfs v0.19 on stock Ubuntu Natty (kernel 2.6.38) > and use a BTRFS inside an encrypted LVM. > > The wiki "gotchas" page https://btrfs.wiki.kernel.org/index.php/Gotchas > states : > « btrfs volumes on top of dm-crypt block devices (and possibly LVM) > require write-caching to be turned off on the underlying HDD. Failing to > do so, in the event of a power failure, may result in corruption not yet > handled by btrfs code. (2.6.33) » > > ...So I''ve turned my write cache off, but I notice this is stated for > kernel 2.6.33, so wonder if this still is an issue with 2.6.38, or has > it been addressed since ? > > Thanks in advance for your help.If you mount and start writing and don''t see a message in dmesg about disabling barriers then you should be good to go. Thanks, Josef -- 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
Hi, Le jeudi 12 mai 2011 à 11:42 -0400, Josef Bacik a écrit :> > > > ...So I''ve turned my write cache off, but I notice this is stated for > > kernel 2.6.33, so wonder if this still is an issue with 2.6.38, or has > > it been addressed since ?> If you mount and start writing and don''t see a message in dmesg about disabling > barriers then you should be good to go. Thanks,I''ve turned disk cache back on and don''t see no such messages in my logs... So I assume I should be safe ? However shifting from ext3 to BTRFS has been enough to turn my perfectly stable system into a perfectly unstable and crash-prone system :-/ -- 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 Fri, May 13, 2011 at 4:36 AM, Swâmi Petaramesh <swami@petaramesh.org> wrote:> However shifting from ext3 to BTRFS has been enough to turn my perfectly > stable system into a perfectly unstable and crash-prone system :-/Well, first of all, btrfs is still under heavy development. Add to that the fact that you use Ubuntu Natty, which also have some known bugs. There should be some hints there on what the outcome would be :P Anyway, I''m using linux-image-2.6.38-9-generic from natty-proposed, with btrfs as "/", separate /boot/grub on ext4, and Corsair Force SSD. It works great so far. If you''re used to ext4 speed, then you''ll notice that btrfs is considerably slower. That''s why I use SSD to add some I/O speed (currently booting to gnome classic desktop only takes about 30 seconds). So in summary, if you have problems but still want to try btrfs, try upgrading your kernel. If you think it''s too slow to be usable, then the best you can try right now is use SSD. -- Fajar -- 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
Hi Fajar, Le vendredi 13 mai 2011 à 13:54 +0700, Fajar A. Nugraha a écrit :> Well, first of all, btrfs is still under heavy development.The wiki https://btrfs.wiki.kernel.org/index.php/Main_Page says in bold: « Btrfs is under heavy development, but every effort is being made to keep the filesystem stable and fast. As of 2.6.31, we only plan to make forward compatible disk format changes, and many users have been experimenting with Btrfs on their systems with good results. » Adding to the fact that it comes included with the stock and distro kernels... That gives a bit contradictory signals... "Should I stay or should I go ?" Looks a bit like legal babble boiling down to « Yes, it is supposed to work and be usable, so please use it, just be so kind no to sue us if you run into trouble. Not our fault, we won''t accept any liability. »> Add to that the fact that you use Ubuntu Natty, which also have some known > bugs. There should be some hints there on what the outcome would be :PEvery distro has bugs. However Natty''s kernel never ever hanged my system until I shifted to using BTRFS... I won''t relate BTRFS issues to using Natty unless there is some evidence pointing in this direction... Not wanting to troll, of course, uh... ;-)> If you''re used to ext4 speed, then you''ll notice that btrfs is considerably > slower. That''s why I use SSD to add some I/O speed (currently booting to gnome > classic desktop only takes about 30 seconds).Well, I noticed it''s slower, still usable for me anyway, I''m a patient guy ;-) Anyway an SSD is not an option to me, financially speaking ;-) Kind regards. -- 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 Fri, May 13, 2011 at 3:59 PM, Swâmi Petaramesh <swami@petaramesh.org> wrote:> Adding to the fact that it comes included with the stock and distro > kernels... That gives a bit contradictory signals... "Should I stay or > should I go ?" > > Looks a bit like legal babble boiling down to « Yes, it is supposed to > work and be usable, so please use it, just be so kind no to sue us if > you run into trouble. Not our fault, we won''t accept any liability. »Something like that. Note also since it''s in heavy development, even a small difference in kernel version can make a difference between whether a bug is present or not, so it''s advisable to always try latest kernel version.> >> Add to that the fact that you use Ubuntu Natty, which also have some known >> bugs. There should be some hints there on what the outcome would be :P > > Every distro has bugs. However Natty''s kernel never ever hanged my > system until I shifted to using BTRFS... I won''t relate BTRFS issues to > using Natty unless there is some evidence pointing in this direction... > > Not wanting to troll, of course, uh... ;-)No troll taken. Just wanted to point out that since Natty is new and has known bugs (which might include kernel package as well), if you encounter problems try to use latest available kernel for Natty first. If it doesn''t work, try latest vanilla kernel from kernel.org. For example, IIRC 2.6.38 has a bug in that you can''t use mount option "subvol=..." if the fs/subvolume is newly created, while 2.6.39 works fine. At least that''s what I experienced, so now I use subvolid to select subvolume.> >> If you''re used to ext4 speed, then you''ll notice that btrfs is considerably >> slower. That''s why I use SSD to add some I/O speed (currently booting to gnome >> classic desktop only takes about 30 seconds). > > Well, I noticed it''s slower, still usable for me anyway, I''m a patient > guy ;-) Anyway an SSD is not an option to me, financially speaking ;-)A 60GB Corsair Force should be about $140. Highly recommended. Higher capacities provide even better cost/GB. -- Fajar -- 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
Le vendredi 13 mai 2011 à 16:16 +0700, Fajar A. Nugraha a écrit :> IIRC 2.6.38 has a bug in that you can''t use mount option "subvol=..." > if the fs/subvolume is newly created, while 2.6.39 works fine. At > least that''s what I experienced, so now I use subvolid to select > subvolume.# uname -a Linux tethys 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux # grep btrfs fstab /dev/VG1/TETHYS / btrfs subvol=UBUNTU,compress=zlib,relatime 0 0 /dev/sda2 /boot btrfs compress=zlib,relatime 0 0 /dev/VG1/TETHYS /home btrfs subvol=HOME,compress=zlib,relatime 0 0 /dev/VG1/TETHYS /tmp btrfs subvol=TMP,compress=zlib,relatime 0 0 /dev/VG1/TETHYS /var btrfs subvol=VAR,compress=zlib,relatime 0 0 # mount | grep btrfs /dev/mapper/VG1-TETHYS on / type btrfs (rw,relatime,subvol=UBUNTU,compress=zlib) /dev/mapper/VG1-TETHYS on /tmp type btrfs (rw,relatime,subvol=TMP,compress=zlib) /dev/mapper/VG1-TETHYS on /home type btrfs (rw,relatime,subvol=HOME,compress=zlib) /dev/mapper/VG1-TETHYS on /var type btrfs (rw,relatime,subvol=VAR,compress=zlib) /dev/sda2 on /boot type btrfs (rw,relatime,compress=zlib) (Maybe worth noting that /boot actually points to a subvol as well, which is set as default subvol as grub2 would seem not to manage non-default subvol)> A 60GB Corsair Force should be about $140. Highly recommended. Higher > capacities provide even better cost/GB.I''ll note this for my next national lottery win ;-))) -- 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 Fri, May 13, 2011 at 4:33 PM, Swâmi Petaramesh <swami@petaramesh.org> wrote:> # uname -a > Linux tethys 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC > 2011 i686 i686 i386 GNU/Linux > > # mount | grep btrfs > /dev/mapper/VG1-TETHYS on / type btrfs > (rw,relatime,subvol=UBUNTU,compress=zlib) > /dev/mapper/VG1-TETHYS on /tmp type btrfs > (rw,relatime,subvol=TMP,compress=zlib) > /dev/mapper/VG1-TETHYS on /home type btrfs > (rw,relatime,subvol=HOME,compress=zlib) > /dev/mapper/VG1-TETHYS on /var type btrfs > (rw,relatime,subvol=VAR,compress=zlib) > /dev/sda2 on /boot type btrfs (rw,relatime,compress=zlib) >Weird. $ sudo btrfs su li / ID 256 top level 5 path natty ID 258 top level 5 path home $ sudo mount /dev/sda2 -o subvol=home /mnt/tmp $ ls /mnt/tmp $ sudo umount /mnt/tmp $ sudo mount /dev/sda2 -o subvolid=258 /mnt/tmp $ ls /mnt/tmp user $ sudo umount /mnt/tmp $ uname -a Linux HP 2.6.38-9-generic #43-Ubuntu SMP Thu Apr 28 15:25:15 UTC 2011 i686 i686 i386 GNU/Linux I don''t even know what got mounted when I use "-o subvol=home" since all of my subvolumes have some files/directory on it, while the mount shows nothing on it :P -- Fajar -- 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
Le vendredi 13 mai 2011 à 16:16 +0700, Fajar A. Nugraha a écrit :> if you encounter problems try to use latest available kernel for Natty > first. If it doesn''t work, try latest vanilla kernel from kernel.org.When I was younger I used to spend days compiling and installing and testing things, and playing with custom kernels, then system upgrades were a week of nightmares, and my wife would kill me and my kids would sell drugs and burn cars instead of doing their homework etc... Now I''m more of the "If it ain''t broke, don''t fix it !" kind, and try to stick as much as possible to my official distro packages as long as I don''t run into damn hell unsolvable issues that force me to enter the DIY-source-tree-compile-nightmare again... And keep in peace with my wife and sleep with her at night rather than compile kernels ;-) In other words, I will consider using an experimental or non-Ubuntu kernel when my filesystem breaks to the point I get no other option but a complete system reinstallation... Otherwise I''ll expect kernel improvements in Ubuntu 11.10 ;-) -- 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