Can lgetxattr legally return ENODATA?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please excuse my ignorance here, but I wondered if this could be a BTRFS related issue... and perhaps one which might not often be spotted if it is. A friend of mine has been having trouble with a backup application on a BTRFS filesystem, and recently sent me this, which made me think that there might be an edge case where something weird is happening:- Not sure if your interested but I thought I'd get my hands dirty and try and figure this boxbackup problem out. stracing the problem gave me this as the cause: lgetxattr(/srv/WWW/Stuff/includes/CI-application/views/objects/items, system.posix_acl_default, 0x0, 0) = -1 ENODATA (No data available) I looked up the call here: http://linux.die.net/man/2/lgetxattr But unfortunately it doesn't have the ENODATA error listed (its not on the stat page it refers to either) Boxbackup assumes it can only be caused by a file permissions problem and so gives that error I had, but the fact that a folder next to it with identical permissions is fine is odd. In the end I copied all the files out with SAMBA, deleted them on the BTRFS volume and put them back in again. After setting the permissions the same as they were before and restarting boxbackup the problem vanished. - -- A. James Lewis (ja...@fsck.co.uk) Engineering does not require science. Science helps a lot but people built perfectly good brick walls long before they knew why cement works. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk+IsT0ACgkQ1OQXXvP2GMFl4wCbB+bcK5gtkgOhHXYsOV2DV7wG RWgAnj+6rX3RogB8gopEkxhV4EVlaxaZ =o9Xj -END PGP SIGNATURE- -- 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
Re: Mis-Design of Btrfs?
On Wed, 2011-06-29 at 10:29 +0100, Ric Wheeler wrote: On 06/27/2011 07:46 AM, NeilBrown wrote: On Thu, 23 Jun 2011 12:53:37 +0200 Nico Schottelius nico-lkml-20110...@schottelius.org wrote: Good morning devs, I'm wondering whether the raid- and volume-management-builtin of btrfs is actually a sane idea or not. Currently we do have md/device-mapper support for raid already, btrfs lacks raid5 support and re-implements stuff that has already been done. I'm aware of the fact that it is very useful to know on which devices we are in a filesystem. But I'm wondering, whether it wouldn't be smarter to generalise the information exposure through the VFS layer instead of replicating functionality: Physical: USB-HD SSD USB-Flash | Exposes information to Raid: Raid1, Raid5, Raid10, etc.| higher levels Crypto: Luks | LVM:Groups/Volumes| FS: xfs/jfs/reiser/ext3 v Thus a filesystem like ext3 could be aware that it is running on a USB HD, enable -o sync be default or have the filesystem to rewrite blocks when running on crypto or optimise for an SSD, ... I would certainly agree that exposing information to higher levels is a good idea. To some extent we do. But it isn't always as easy as it might sound. Choosing exactly what information to expose is the challenge. If you lack sufficient foresight you might expose something which turns out to be very specific to just one device, so all those upper levels which make use of the information find they are really special-casing one specific device, which isn't a good idea. However it doesn't follow that RAID5 should not be implemented in BTRFS. The levels that you have drawn are just one perspective. While that has value, it may not be universal. I could easily argue that the LVM layer is a mistake and that filesystems should provide that functionality directly. I could almost argue the same for crypto. RAID1 can make a lot of sense to be tightly integrated with the FS. RAID5 ... I'm less convinced, but then I have a vested interest there so that isn't an objective assessment. Part of the way Linux works is that s/he who writes the code gets to make the design decisions. The BTRFS developers might create something truly awesome, or might end up having to support a RAID feature that they subsequently think is a bad idea. But it really is their decision to make. NeilBrown One more thing to add here is that I think that we still have a chance to increase the sharing between btrfs and the MD stack if we can get those changes made. No one likes to duplicate code, but we will need a richer interface between the block and file system layer to help close that gap. Ric Is there a possibility that one could have a 3 disk RAID5 array, and then add a 4th disk and then do a balance, growing the RAID5 onto 4 disks and gaining the space still with RAID5? It seems that to be consistent, BTRFS would have to do this. If this is the case, then I think that the BTRFS implementation of RAID5 would have to be quite different to the MD implementation. James. -- 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 -- 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
Confusing...
After completing an installation of Ubuntu 11.04 with a separate /boot partition and BTRFS as the main filesystem (Ubuntu creates subvolumes for / and /home). sda1 being the GPT stuff sda2 being most of the disk as BTRFS sda3 being /boot sda4 being swap sdb having an identical partition table... I patched everything up to date, rebooted to make sure that all was ok.. and then ran:- btrfs device add /dev/sdb2 / sync reboot The system stops in initrd unable to find the root filesystem... It's my understanding that nothing should change here, am I missing something, I don't see how it can even tell I've added more storage, let alone fail to boot. -- A. James Lewis (ja...@fsck.co.uk) Engineering does not require science. Science helps a lot but people built perfectly good brick walls long before they knew why cement works. -- 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
Re: Excluding a device from storing snapshot data?
On Tue, 2011-02-15 at 23:58 +0100, Bert Wesarg wrote: Hi all, I'm currently envision a backup setup for my laptop which has a SSD. I would like to use an external HDD und span a raid1 over these two devices and also creating snapshots. What I would like to prevent, is that these snapshots take storage space on the SSD, because SSD storage is precious, while this isn't true for the external HDD. So I would need to exclude the SSD device to store snapshot data, or to be more precise, to store only one specific subvolume. Which can obviously be changing, if I need to restore a previous snapshot. Is this currently or actually possible? I would say that it is not actually possible... because when you create a snapshot, no actual data is generated, the snapshot is initially only metadata pointing to the same blocks on disk as the original data... Changes being written in a new location so over time retaining the snapshot will have a storage overhead, but the process of creating the snapshot doesn't write anything, and any new data written is part of the real data, not the snapshot. Perhaps a more pertinent question is Are there any plans to implement any kind of Hierarchical Storage Management in BTRFS... I'm not sure how complex it actually would be to implement, but having some understanding of the speed of devices and the frequency of access to particular blocks could allow the data to be re-balanced in favour of placing frequently accessed blocks on faster storage. Anyone have a comment on this? Thanks. Bert -- 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
Re: Corrupt filesystem after power failure
I'm far from an expert here, but perhaps you would be worth trying a newer version of the BTRFS drivers, either via a newer kernel or re-compiling a kernel with updated BTRFS patches. I would think that the simplest quick test to see if this would help you would be to get a snapshot from Ubuntu's daily build live CD iso, and try mounting the filesystem with that... since it will have a recent RC of 2.6.38 kernel which has a much more recent BTRFS version than the 2.6.34 which you are using. http://cdimage.ubuntu.com/daily-live/current/ YMMV, but it's certainly something else to try. James. On Thu, 2011-02-10 at 22:29 +1100, Anil Kumar wrote: Hi, I am using btrfs on my /home successfully for a while now. After a power failure I am no longer able to mount it. I tried to use btrfsck without any success. The backup I have is about a month old, is there a way I can salvage my files?. Full backtrace is at http://pastebin.com/4Re7tVFP I am aware of the danger of dataloss and wanted to change the filesystem. Anyway it's too late now Anil -- 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 -- 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
Re: Recover Corruption - verify_parent_transid
Not being one of the developers on this project, I cannot offer you a solution to recovering data from this volume, and my guess is that a ready solution is unlikely to be forthcoming simply because if this was possible then btrfsck would include the code to recover the filesystem already. However, rather than simply observe that anything not backed up is lost... I thought I would offer the solution of the 4th dimension The data is not lost, but simply unavailable to you until the tools to repair the filesystem have been developed further. If I had something critical which had become inaccessible, I might be tempted to put the drive on a shelf for 6 months and see if btrfsck was able to repair filesystems by then. It may be that the on disk format is changed before that happens, but I understand that this is now relatively unlikely. A. James Lewis -- 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
Re: 2.6.35 performance results
On Fri, Aug 06, 2010 at 01:44:11PM -0500, Steven Pratt wrote: Here is the latest set of performance runs from the 2.6.35-rc5 tree. Included is a refresh of all the other filesystems with some changes for barriers on and off since this has been somewhat of a hot topic recently. New data linked in to the history graphs here: http://btrfs.boxacle.net/repository/raid/history/History.html From a BTRFS performance perspective, we took a major regression on write heavy workloads. As much as a 10x hit! The problems seems to be due to this changeset: http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=5da9d01b66458b180a6bee0e637a1d0a3effc622 Ouch! The problem is we're not being aggressive enough about allocating chunks for data, which makes the flusher come in and start data IO. Thanks a lot for finding the regression, my machine definitely didn't show this. I'll reproduce and fix it up. The guys testing this in Ubuntu's Maverick Alpha's have noticed this too... It happens only in some configurations... for example, I tested in a VM and did not see any issue, but when installing for real on the same hardware performance fell through the floor. https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/601299?comments=all -chris Btrfs: Shrink delay allocated space in a synchronized Shrink delayed allocation space in a synchronized manner is more controllable than flushing all delay allocated space in an async thread. This changeset introduced btrfs_start_one_delalloc_inode in http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commitdiff;h=5da9d01b66458b180a6bee0e637a1d0a3effc622 In heavy write workloads this new function is now dominating the profiles: samples %app name symbol name 8914973 65.1261 btrfs.ko btrfs_start_one_delalloc_inode 1024841 7.4867 vmlinux-2.6.35-rc5-autokern1 rb_get_reader_page 7160465.2309 vmlinux-2.6.35-rc5-autokern1 ring_buffer_consume 3153542.3037 oprofile.ko add_event_entry 2024841.4792 vmlinux-2.6.35-rc5-autokern1 write_inode_now 1950181.4247 btrfs.ko btrfs_tree_lock Appears to be major contention on the spin lock, as this gets worse with more threads. This needs to be redone. Steve -- 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
Re: Configuring default mount options..
From: Oystein Viggen oysteivi at tihlde.org Subject: Re: Configuring default mount options.. Newsgroups: gmane.comp.file-systems.btrfs Date: 2010-07-26 06:08:54 GMT (5 hours and 4 minutes ago) * [A. James Lewis] Maybe there is a way to do this already, but it seems like the filesystem itself should contain preferences for the way it is used under those circumstances. There has been talk of supporting per-file (and I assume recursive per-directory default) attributes for raid level. Things like encryption and compression could fit well into such a scheme. That's a nice solution, particularly for encryption... especially once the GUI file managers are able to indicate the settings It would seem to be necessary to allow these parameters to be set in the root, but otherwise nice. I'm not sure if it negates the value of having default preferences stored somwhere... certainly it would take longer to implement, but maybe the default parameters for all these settings are simply equivalent to whatever is defined in the root of each filesystem... so really one solution can be a subset of the other. I don't believe the code for this is written yet, however. Øystein -- ssh -c rot13 otherhost A. James Lewis -- 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
Configuring default mount options..
If using BTRFS on a removable drive... it may be a problem for example, to always mount with compression, or always mount with encryption (If supported in future)... perhaps btrfstune could define default mount options, such as compression... so if there is a BTRFS filesystem on a removable hard drive, or flash stick, the filesystem can be configured to mount with compression by default. Maybe there is a way to do this already, but it seems like the filesystem itself should contain preferences for the way it is used under those circumstances. A. James Lewis -- 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
Re: Configuring default mount options..
On Mon, 2010-07-26 at 03:10 +0200, Sebastian 'gonX' Jensen wrote: On 26 July 2010 02:56, A. James Lewis ja...@fsck.co.uk wrote: If using BTRFS on a removable drive... it may be a problem for example, to always mount with compression, or always mount with encryption (If supported in future)... perhaps btrfstune could define default mount options, such as compression... so if there is a BTRFS filesystem on a removable hard drive, or flash stick, the filesystem can be configured to mount with compression by default. Maybe there is a way to do this already, but it seems like the filesystem itself should contain preferences for the way it is used under those circumstances. A. James Lewis -- 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 That's actually a good idea. Perhaps an override flag could be specified in case you do not wish to use said default mount options? Indeed, if any mount options are specified they would override defaults... but if you plug in a removable drive, you there's no way to specify mount options, but it's quite likley that you would want some, like compression for example. Regards, Sebastian J. -- 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
