Just compiled a custom kernel, but unable to mount a btrfs partition. It essentially says ''unrecognized filesystem''. What could be missing? # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y CONFIG_EXT3_DEFAULTS_TO_ORDERED=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_XATTR=y # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set # CONFIG_EXT4_DEBUG is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_JBD2=y # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set CONFIG_JFS_FS=y # CONFIG_JFS_POSIX_ACL is not set # CONFIG_JFS_SECURITY is not set # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_BTRFS_FS=y CONFIG_BTRFS_FS_POSIX_ACL=y # CONFIG_NILFS2_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_FILE_LOCKING=y CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_FANOTIFY is not set CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y CONFIG_PRINT_QUOTA_WARNING=y # CONFIG_QUOTA_DEBUG is not set CONFIG_QUOTA_TREE=m # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=y CONFIG_FUSE_FS=y CONFIG_CUSE=y CONFIG_GENERIC_ACL=y -- 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 09.07.2011 18:19, CACook@quantum-sci.com wrote:> Just compiled a custom kernel, but unable to mount a btrfs partition. It essentially says ''unrecognized filesystem''. What could be missing? > > # File systems > # > CONFIG_EXT2_FS=y > CONFIG_EXT2_FS_XATTR=y > CONFIG_EXT2_FS_POSIX_ACL=y > CONFIG_EXT2_FS_SECURITY=y > # CONFIG_EXT2_FS_XIP is not set > CONFIG_EXT3_FS=y > CONFIG_EXT3_DEFAULTS_TO_ORDERED=y > CONFIG_EXT3_FS_XATTR=y > CONFIG_EXT3_FS_POSIX_ACL=y > CONFIG_EXT3_FS_SECURITY=y > CONFIG_EXT4_FS=y > CONFIG_EXT4_FS_XATTR=y > # CONFIG_EXT4_FS_POSIX_ACL is not set > # CONFIG_EXT4_FS_SECURITY is not set > # CONFIG_EXT4_DEBUG is not set > CONFIG_JBD=y > # CONFIG_JBD_DEBUG is not set > CONFIG_JBD2=y > # CONFIG_JBD2_DEBUG is not set > CONFIG_FS_MBCACHE=y > # CONFIG_REISERFS_FS is not set > CONFIG_JFS_FS=y > # CONFIG_JFS_POSIX_ACL is not set > # CONFIG_JFS_SECURITY is not set > # CONFIG_JFS_DEBUG is not set > # CONFIG_JFS_STATISTICS is not set > # CONFIG_XFS_FS is not set > # CONFIG_GFS2_FS is not set > # CONFIG_OCFS2_FS is not set > CONFIG_BTRFS_FS=y > CONFIG_BTRFS_FS_POSIX_ACL=y > # CONFIG_NILFS2_FS is not set > CONFIG_FS_POSIX_ACL=y > CONFIG_FILE_LOCKING=y > CONFIG_FSNOTIFY=y > CONFIG_DNOTIFY=y > CONFIG_INOTIFY_USER=y > # CONFIG_FANOTIFY is not set > CONFIG_QUOTA=y > CONFIG_QUOTA_NETLINK_INTERFACE=y > CONFIG_PRINT_QUOTA_WARNING=y > # CONFIG_QUOTA_DEBUG is not set > CONFIG_QUOTA_TREE=m > # CONFIG_QFMT_V1 is not set > CONFIG_QFMT_V2=m > CONFIG_QUOTACTL=y > CONFIG_QUOTACTL_COMPAT=y > CONFIG_AUTOFS4_FS=y > CONFIG_FUSE_FS=y > CONFIG_CUSE=y > CONFIG_GENERIC_ACL=yIf your btrfs lives on two or more devices you will have to run ''btrfs device scan'' prior to mount or give all devices as arguments to mount.btrfs. Andreas -- 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 Saturday 9 July, 2011 10:12:43 you wrote:> If your btrfs lives on two or more devices you will have to run ''btrfs > device scan'' prior to mount or give all devices as arguments to mount.btrfs.Ohhh, I''d added a disk drive without modifying fstab. Thanks. Where would you put a device scan to happen at boot? On another subject, I guess there are two ways to remove old snapshot directories: - btrfs subvolume delete - rm -rf I understand that snapshots are cumulative for files and do not duplicate, but is it necessary to use the subvolume delete command to preserve the integrity of remaining snapshots? And also, about once a week KDE locks up on me after a suspend, and I have to power-cycle it. Is there any maintenance I should do on a btrfs part when this happens? -- 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
Hallo, Cacook, Du meintest am 09.07.11:> Just compiled a custom kernel, but unable to mount a btrfs partition. > It essentially says ''unrecognized filesystem''. What could be > missing?Perhaps you only need a newer kernel. Sounds funny, but some days ago I had a similar problem, with kernel 2.6.38.5 Then I compiled kernel 2.6.39.2 - all worked as well as (about) a week ago. Maybe I can''t reproduce this behaviour, but I don''t want to see it again - restoring more than 4 TByte is no fun. Viele Gruesse! Helmut -- 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 Sat, Jul 09, 2011 at 10:28:03AM -0700, CACook@quantum-sci.com wrote:> On Saturday 9 July, 2011 10:12:43 you wrote: > > If your btrfs lives on two or more devices you will have to run ''btrfs > > device scan'' prior to mount or give all devices as arguments to mount.btrfs. > > Ohhh, I''d added a disk drive without modifying fstab. Thanks. > > Where would you put a device scan to happen at boot?This is distribution dependent, but I do know that Debian will put it in your initrd for you if you install Debian''s btrfs-tools package. If you have your root FS on btrfs, you *must* put the scan in an initrd (or specify all the root devices as mount options in your kernel command-line). If you don''t use an initrd, then add the scan to your startup scripts anywhere before the point that filesystems are mounted, and anywhere after the point that block devices are detected (typically when udev is started).> On another subject, I guess there are two ways to remove old snapshot directories: > - btrfs subvolume delete > - rm -rf > > I understand that snapshots are cumulative for files and do not duplicate, but is it necessary to use the subvolume delete command to preserve the integrity of remaining snapshots?No, effectively each snapshot is independent of the others (by the magic of copy-on-write). When items from a snapshot are deleted, the filesystem automatically cleans up by updating the extent reference counts.> And also, about once a week KDE locks up on me after a suspend, and > I have to power-cycle it. Is there any maintenance I should do on a > btrfs part when this happens?No, if the storage stack from filesystem all the way down to the drive platter handles barriers correctly, then btrfs should always be in a consistent state, even over a power-cycle. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Welcome to Rivendell, Mr Anderson... ---
Did you ever say something positive about btrfs? :D All I read from in the last months is complaining about btrfs. In this case it was his fault because he forget to update the fstab. Im pretty sure it was also your fault when you screwed up your 2.6.38.5 kernel... I''m sorry but it seems that 90% for your comments are useless and they sound like you only want to say something bad about btrfs. Regards, Felix On 7/9/11 1:33 PM, Helmut Hullen wrote:> Hallo, Cacook, > > Du meintest am 09.07.11: > >> Just compiled a custom kernel, but unable to mount a btrfs partition. >> It essentially says ''unrecognized filesystem''. What could be >> missing? > > Perhaps you only need a newer kernel. Sounds funny, but some days ago I > had a similar problem, with kernel 2.6.38.5 > > Then I compiled kernel 2.6.39.2 - all worked as well as (about) a week > ago. > > Maybe I can''t reproduce this behaviour, but I don''t want to see it again > - restoring more than 4 TByte is no fun. > > Viele Gruesse! > Helmut > -- > 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
Hallo, Felix, Du meintest am 10.07.11:> Did you ever say something positive about btrfs? :D All I read from > in the last months is complaining about btrfs.I use it, since many months. But it''s still an adventure, I won''t use it for valuable data.> I''m sorry but it seems that 90% for your comments are useless and > they sound like you only want to say something bad about btrfs.Do you really mean that this is a mailing list where everybody has to tell "it works!"? The most mailing list where I''m subscribed mostly have threads starting with "Houston, we''ve got a problem". ----------------------------- By the way: I''m writing programs since more than 40 years, I know that nearly every program contains errors which the programmer didn''t wish or expect. The programmer needs the reactions of the users. Viele Gruesse! Helmut -- 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 07/09/2011 07:28 PM, CACook@quantum-sci.com wrote:> On Saturday 9 July, 2011 10:12:43 you wrote: >> If your btrfs lives on two or more devices you will have to run >> ''btrfs device scan'' prior to mount or give all devices as arguments >> to mount.btrfs. > > Ohhh, I''d added a disk drive without modifying fstab. Thanks. > > Where would you put a device scan to happen at boot?The more recent distro put the scanning logic in the initrd. This should be the right place.> On another subject, I guess there are two ways to remove old snapshot > directories: - btrfs subvolume delete - rm -rfwith rm -rf you can remove only the subvolume contents, but you cannot delete a subvoulume.> > I understand that snapshots are cumulative for files and do not > duplicate, but is it necessary to use the subvolume delete command to > preserve the integrity of remaining snapshots?No. Apart removing the subvolume entry, "rm -rf" and "btrfs subvolume delete" reach the same result. The latter is only a lot more efficient.> And also, about once a week KDE locks up on me after a suspend, and I > have to power-cycle it. Is there any maintenance I should do on a > btrfs part when this happens?Normally you don''t do anything. In any case you are not able to do anything because there no is a tool like fsck available :-)> > -- 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
You don''t understood me. Ofc the developer need bug reports and all that stuff. But it''s the way youre doing it. Imho a lot of your mails sounds like the only goal of them are to punish btrfs. Maybe I''m the only one who feels this way, then I''m sorry. I''ll be quite about this topic now. I''ve to admit that I was a little bit drunk yesterday. Sorry again! Regards, Felix On 7/10/11 3:29 AM, Helmut Hullen wrote:> Hallo, Felix, > > Du meintest am 10.07.11: > >> Did you ever say something positive about btrfs? :D All I read from >> in the last months is complaining about btrfs. > > I use it, since many months. > But it''s still an adventure, I won''t use it for valuable data. > >> I''m sorry but it seems that 90% for your comments are useless and >> they sound like you only want to say something bad about btrfs. > > Do you really mean that this is a mailing list where everybody has to > tell "it works!"? > > The most mailing list where I''m subscribed mostly have threads starting > with "Houston, we''ve got a problem". > > ----------------------------- > > By the way: I''m writing programs since more than 40 years, I know that > nearly every program contains errors which the programmer didn''t wish or > expect. The programmer needs the reactions of the users. > > Viele Gruesse! > Helmut > -- > 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
Hallo, Felix, Du meintest am 10.07.11:> I''ll be quiet about this topic now. I''ve to admit that I was a little > bit drunk yesterday. Sorry again!Don''t drink and write! Viele Gruesse! Helmut -- 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
Well, the mail still says the truth :) On 7/10/11 11:57 AM, Helmut Hullen wrote:> Hallo, Felix, > > Du meintest am 10.07.11: > >> I''ll be quiet about this topic now. I''ve to admit that I was a little >> bit drunk yesterday. Sorry again! > > Don''t drink and write! > > Viele Gruesse! > Helmut > -- > 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