Re: [PATCH v0 07/18] btrfs: generic data structure to build unique lists
On 06.10.2011 22:33, Andi Kleen wrote: Arne Jansen sensi...@gmx.net writes: ulist is a generic data structures to hold a collection of unique u64 values. The only operations it supports is adding to the list and enumerating it. It is possible to store an auxiliary value along with the key. The implementation is preliminary and can probably be sped up significantly. It is used by subvolume quota to translate recursions into iterative loops. Hmm, sounds like a job for lib/idr.c What do your ulists do that idr doesn't? Ok idr doesn't have merge, but that should be simple enough to add. This is indeed a part I'm not feeling particularly well about, adding a generic data structure to btrfs instead of to the core. If I'm not the only one feeling this data structure might be handy outside of btrfs, I can move it, if someone points me to the right place. Since I built it, I found many applications for it, so I have some hopes I won't stay the only one to like it. Of course the current version is not very optimized, though on small sets it should work well. As to the differences to idr: - as David pointed out, idr works on int, while I always need u64 to represent btrfs logical addresses. - as I understand idr (though I never used it), it is designed to manage small consecutive integers, while ulists hold completely unrelated numbers, e.g. btrfs logical adresses. For small sets ulists might be much faster than idr - ulists as used here are very short lived. I don't know if idr handles this case well - the purpose of ulists is to add a specific number, and not to find a free one. I don't see a direct interface for this in idr. -Arne -Andi -- 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: Honest timeline for btrfsck
For fsck, even the stuff I have here does have a way to go before it is at the level of an e2fsck or xfs_repair. But I do want to make sure that I'm surprised by any bugs before I send it out, and that's just not the case today. The release has been delayed because I've alternated between a few different ways of repairing, and because I got distracted by some important features in the kernel. I think there is a major difference between touching up a few bugs before you release the code, and experimenting with a bunch of different ways of repairing before you release the code. I know I for one would get as much value out of reading the code for the strategies you abandoned as I would get from reading the final code, but I don't know if having those branches in the main repo would have any value for the project as a whole. As the current solution goes, I'd just like to see a stake in the ground for some sort of process to move away from the one man army approach, should distractions etc continue. Given the latest 2 week estimate, something along the lines of, in 4 or 6 weeks, if it still isn't 'ready', code will start to be released. That's how software goes sometimes, and I'll take the criticism because it hasn't gone as well as it should have. But, I can't stress enough how much I appreciate everyone's contributions and interest in btrfs. -chris I'm only criticizing the decision to not release the source, in particular given the delays. We all have our priorities and distractions, and s**t happens. (Part of why I'd argue against the flying solo strategy.) But, I really do appreciate all the stuff you've built, which is part of why I am so keen on reading it. :-) . Thanks for all the effort --jeff -- 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: Honest timeline for btrfsck
On 10/06/2011 04:56 PM, Francesco Riosa wrote: 2011/10/6 Andi Kleen a...@firstfloor.org: Jeff Putney jeffrey.put...@gmail.com writes: http://en.wikipedia.org/wiki/Release_early,_release_often Well the other principle in free software you're forgetting is: It will be released when it's ready If you don't like Chris' ways to do releases you're free to write something on your own or pay someone to do so. Otherwise you just have to deal with his time frames, as shifty as they may be. I did a different thing, I've offered Chris money to help rescue an hosed btrfs or to point to someone who could do, we ended in doing some tests (for free) but nothing else materialized. While the time passed has diminished the value of the data to be rescued I'm more on the show us some code we can start from than it will be released when ready vagon. If you still need that data, clone this repo git://github.com/josefbacik/btrfs-progs.git run make, and then run ./restore /dev/whatever /some/dir and it will try and suck all of your data off the disk and dump it in that directory. If you have snapshots it will skip them by default, so if you have snapshots that have useful data in them you'll want to use the -s option. If you run into random errors that you think are recoverable, or if you don't care about the file that's being recovered, you can run with -i which will ignore errors and keep trying to recover your files. Thanks, Josef -- 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: A Plumber’s Wish List for Linux
On Fri, Oct 07, 2011 at 02:46:23PM +0200, Kay Sievers wrote: On Fri, Oct 7, 2011 at 12:38, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Fri, 7 Oct 2011 12:28:46 +0200 Kay Sievers kay.siev...@vrfy.org wrote: What do you mean would be ugly? I have an ext4fs. It supports every possible file name allowed by POSIX and SuS. What name are you going to use for your 'hidden directory' that won't clash with a real file ? Ah, no. The label on FAT (similar on NTFS) are 'magic entries' in the root dir list, not a real file in the root dir. We need kernel support for changing a mounted fs, because, unlike ext4, the blocks containing the strings are inside the fs, which the kernel might change any time. It's worth noting that there are similar issues with btrfs around changing label. A common API for it would make sense. The only btrfs patches I've seen to change label after mkfs-time work either as: * unmounted only, single underlying device only, pure userspace implementation * mounted only, multiple underlying devices, kernel support needed The kernel-side patches never got integrated, so we're still unable to change the label on the majority of btrfs filesystems. Changing the UUID for the filesystem is even harder, as I think it's written to every metadata block. I'm not sure we can do that sanely on a mounted filesystem. Hugo (just a spear-carrier from the btrfs chorus). -- === 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 --- Anyone using a computer to generate random numbers is, of --- course, in a state of sin. signature.asc Description: Digital signature
Re: Honest timeline for btrfsck
On 11-10-06 07:50 PM, Chris Mason wrote: That's how software goes sometimes, and I'll take the criticism because it hasn't gone as well as it should have. But, I can't stress enough how much I appreciate everyone's contributions and interest in btrfs. With all due respect Chris, your actions and your words seem to contradict each other. It would appear that people are wanting to help contribute, but without showing them the code, you're preventing any contributions from happening. As you know, contributing is more than just code, just as important is proper testing, especially with a fsck tool. I also don't think you are giving people enough credit. e2fsck will cause corruption pretty much everytime its run on a mounted file system, but a nice big nasty warning message seems to handle that quite well and anyone who ignores it, well thats their own fault, not the developers: e2fsck 1.41.14 (22-Dec-2010) /dev/sdb1 is mounted. WARNING!!! The filesystem is mounted. If you continue you ***WILL*** cause ***SEVERE*** filesystem damage. Do you really want to continue (y/n)? cancelled! You could easily place the same warning in btrfs fsck even for normal use and recommend/require that it be run on a loopback image rather than the actual data itself or something. Heck, even have it run in make no changes mode by default and require recompiling to enable fix my filesystem mode. In fact, when its first released that would probably be a good idea to do this anyways. The reality is, it doesn't matter how long you work on the fsck tool, its pretty much guaranteed to be a few bugs that corrupt some peoples data even more than it was before, thats the price you pay for being on the bleeding edge. Don't get me wrong, I definitely appreciate all your work, I just wish I could appreciate it even more with a fsck tool. ;) -- Mike -- 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
[PATCH] Btrfs: wait for ordered extents if we didn't reclaim enough
I noticed recently that my overcommit patch was causing one of my enospc tests to fail 25% of the time with early ENOSPC. This is because my overcommit patch was letting us go way over board, but it wasn't waiting long enough to let the delalloc shrinker do it's job. The problem is we just start writeback and wait a little bit hoping we flush enough, but we only free up delalloc space by having the writes complete all the way. We do this by waiting for ordered extents, which we do but only if we already free'd enough for the reservation, which isn't right, we should flush ordered extents if we didn't reclaim enough in case that will push us over the edge. With this patch I've not seen a failure in this enospc test after running it in a loop for an hour. Thanks, Signed-off-by: Josef Bacik jo...@redhat.com --- fs/btrfs/extent-tree.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 0abf70c..fc0de68 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3406,7 +3406,7 @@ static int shrink_delalloc(struct btrfs_trans_handle *trans, } } - if (reclaimed = to_reclaim !trans) + if (reclaimed to_reclaim !trans) btrfs_wait_ordered_extents(root, 0, 0); return reclaimed = to_reclaim; } -- 1.7.5.2 -- 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: Honest timeline for btrfsck
On 10/07/2011 11:58 AM, Jeff Putney wrote: The rescue tool may have a lot of the logic I personally am most interested in reading. Thank you for that! The problem is people won't just read it, they will use it. I've read every last line of the current btrfsck, even though it doesn't do anything. I am interested in the source specifically to read it. I wrote a basic repair tool for a user in Fedora who seemed to have a very specific kind of corruption, and earlier this week almost a month after my initial repair tool I had to write another tool to go in and just pull all his data off his disk because a bug in my repair tool made his fs _WORSE_, to the point I'm not sure I can fix it. These are specifically the types of one off solutions that are having to be done because the source hasn't been released for the community to finish up. Fsck has the potential to make any users problems worse, and given the increasing number of people putting production systems on btrfs with no backups the idea of releasing a unpolished and not fully tested fsck into the world is terrifying, and would likely cause long term I heard that file system's fsck tool eats babies sort of reputation. I fail to see the distinction between releasing an unpolished fsck vs releasing an unpolished fs driver. They are collaborating parts of the same system. Whether they say btrfsck eats babies or btrfs eats babies, they are still saying that the babies are getting eaten. Release early and release often is nice for web browsers and desktop environments, it's not so nice with things that could result in data loss, especially when our user base is growing in leaps and bounds and aren't necessarily informed enough on the dangers of using an file system that's still under heavy development. What you are saying is that the specter of increased data loss somehow outweighs the combined benefit that the community has to offer. Unless the current state of the project IS due solely to the work of Chris and Josef, and you don't feel that the community at large has provided meaningful contributions, than I think that's a pretty skeptical and unappreciative attitude towards all of the people who HAVE contributed to this project. The 'specialness' of an fsck tool is highly suspect. Current development versions of all the other fsck tools are available in their respective repositories, and yet headlines of their eating babies are still pretty scarce. I'm glad that Linus didn't use your logic when it came to releasing the linux kernel. Do you think the entire linux kernel is more like a web browser, or a desktop environment? This smells more like post hoc justification of being territorial over a pet project than it does actual reasons for keeping the source a state secret of oracle. Unless their is no intention of releasing the source, and Oracle intends to keep it a closed source product for their own linux distributions alone. Well you've caught us, this is all just a conspiracy to keep the users under our thumbs and to block out any contributions. Sorry Chris, we kept it up for a good year tho! Josef -- 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
read error: how to fix?
Hallo,
I'm just copying about 1.5 TByte from a 3-disks-btrfs directory (data:
raid0) to another disk. And there seem to be 2 damaged files, they stop
the copying process.
Oct 7 18:16:55 Arktur kernel: ata5.00: exception Emask 0x0 SAct 0x0
SErr 0x0 action 0x0
Oct 7 18:16:55 Arktur kernel: ata5.00: BMDMA2 stat 0x80d2009
Oct 7 18:16:55 Arktur kernel: ata5.00: failed command: READ DMA
Oct 7 18:16:55 Arktur kernel: ata5.00: cmd c8/00:40:57:d0:34/00:00:00:00:00/ee
tag 0 dma 32768 in
Oct 7 18:16:55 Arktur kernel: res 51/40:40:57:d0:34/00:03:0e:00:00/fe
Emask 0x9 (media error)
Oct 7 18:16:55 Arktur kernel: ata5.00: status: { DRDY ERR }
Oct 7 18:16:55 Arktur kernel: ata5.00: error: { UNC }
Oct 7 18:16:55 Arktur kernel: ata5.00: configured for UDMA/100
Oct 7 18:16:55 Arktur kernel: ata5: EH complete
(repeating every 3 seconds)
The files contain no valuable data (*.mpeg files, reproducable). But how
can I tell the disk not to use the damaged sector(s)?
On an ext2/3 system I used badblocks - is there some comparable tool
for btrfs?
Viele Gruesse!
Helmut
--
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: Honest timeline for btrfsck
You jest, but in fact that is the result you've achieved, through conspiring or not. Do you honestly believe that had the source been public from the start, that after a year there would still be no quality fsck tool? Contributions are, de facto, blocked. Had there not been repeated promise of an fsck utility for the last year, do you honestly believe no one else would have begun development? Call it under your thumb if you'd like, but you'll argue these declarations didn't have a stifling effect in vain. On Fri, Oct 7, 2011 at 11:08 AM, Josef Bacik jo...@redhat.com wrote: On 10/07/2011 11:58 AM, Jeff Putney wrote: The rescue tool may have a lot of the logic I personally am most interested in reading. Thank you for that! The problem is people won't just read it, they will use it. I've read every last line of the current btrfsck, even though it doesn't do anything. I am interested in the source specifically to read it. I wrote a basic repair tool for a user in Fedora who seemed to have a very specific kind of corruption, and earlier this week almost a month after my initial repair tool I had to write another tool to go in and just pull all his data off his disk because a bug in my repair tool made his fs _WORSE_, to the point I'm not sure I can fix it. These are specifically the types of one off solutions that are having to be done because the source hasn't been released for the community to finish up. Fsck has the potential to make any users problems worse, and given the increasing number of people putting production systems on btrfs with no backups the idea of releasing a unpolished and not fully tested fsck into the world is terrifying, and would likely cause long term I heard that file system's fsck tool eats babies sort of reputation. I fail to see the distinction between releasing an unpolished fsck vs releasing an unpolished fs driver. They are collaborating parts of the same system. Whether they say btrfsck eats babies or btrfs eats babies, they are still saying that the babies are getting eaten. Release early and release often is nice for web browsers and desktop environments, it's not so nice with things that could result in data loss, especially when our user base is growing in leaps and bounds and aren't necessarily informed enough on the dangers of using an file system that's still under heavy development. What you are saying is that the specter of increased data loss somehow outweighs the combined benefit that the community has to offer. Unless the current state of the project IS due solely to the work of Chris and Josef, and you don't feel that the community at large has provided meaningful contributions, than I think that's a pretty skeptical and unappreciative attitude towards all of the people who HAVE contributed to this project. The 'specialness' of an fsck tool is highly suspect. Current development versions of all the other fsck tools are available in their respective repositories, and yet headlines of their eating babies are still pretty scarce. I'm glad that Linus didn't use your logic when it came to releasing the linux kernel. Do you think the entire linux kernel is more like a web browser, or a desktop environment? This smells more like post hoc justification of being territorial over a pet project than it does actual reasons for keeping the source a state secret of oracle. Unless their is no intention of releasing the source, and Oracle intends to keep it a closed source product for their own linux distributions alone. Well you've caught us, this is all just a conspiracy to keep the users under our thumbs and to block out any contributions. Sorry Chris, we kept it up for a good year tho! Josef -- 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: Honest timeline for btrfsck
On Fri, 07 Oct 2011 08:39:36 -0700 Mike i...@snappymail.ca wrote: I also don't think you are giving people enough credit. e2fsck will cause corruption pretty much everytime its run on a mounted file system, but a nice big nasty warning message seems to handle that quite well and anyone who ignores it, well thats their own fault, not the developers: +1 -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Honest timeline for btrfsck
On Fri, Oct 7, 2011 at 11:07 AM, Jeff Putney jeffrey.put...@gmail.com wrote: You jest, but in fact that is the result you've achieved, through conspiring or not. Do you honestly believe that had the source been public from the start, that after a year there would still be no quality fsck tool? Contributions are, de facto, blocked. Had there not been repeated promise of an fsck utility for the last year, do you honestly believe no one else would have begun development? Call it under your thumb if you'd like, but you'll argue these declarations didn't have a stifling effect in vain. Heh, what sort of quality are you thinking would develop? A recovery tool by its nature is picking up the pieces where those pieces are inconsistent. The nature of those inconsistencies will change with every patch that's more than a cleanup. Combined with the well-known tendencies of users to not report errors that are trivial to work around, and I find myself quite content with the status quo: a few general recovery techniques that can be found with some digging, inconvenient enough that the reports don't get lost, with enough context that the appropriate warnings and alternatives can be given. Yes, a deliberately broken-by-makefile version of what he's looking at would be interesting, but I suspect it's not much past what any competent programmer would put together given a couple weeks going over the disk format, and we already have a couple of those. What we want is still in Chris' head, otherwise we _would_ have something. --cwillu Warning: while cwillu is never wrong, he may not correspond to reality. cwillu should not be taken with caffeine or alcohol. Contact a doctor immediately if cwillu submits patches, rants, or directives. Do not leave cwillu within reach of children or ubuntuforums users. Always make sufficient backups before taking cwillu. -- 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: [RFC][PATCH 1/2] vfs: allow /proc/pid/maps to return a custom device
Ressurecting an old thread, sorry. Here's the conversation thus far: http://www.spinics.net/lists/linux-btrfs/msg10099.html This is still hitting folks wishing to use btrfs on suse based systems. Using getattr() (unconditionally I might add) is possible, but will affect performance to a far greater degree than just allowing an optional deref of whatever structure btrfs (and similar file systems) have to point to the right block device. Is this really the way we would like to proceed? Chris, maybe you can chime in here? --Mark On Thu, May 19, 2011 at 01:18:26PM -0700, Mark Fasheh wrote: On Sat, May 14, 2011 at 08:06:04PM -0700, Eric W. Biederman wrote: Mark Fasheh mfas...@suse.com writes: This patch introduces a callback in the super_operations structure, 'get_maps_dev' which is then used by procfs to query which device to return for reporting in /proc/[PID]/maps. No. It may make sense to call the vfs stat method. But introducing an extra vfs operations for this seems like a maintenance nightmare. Yeah I'm not thrilled with the extra method either. My concern with using -getattr is whether it's too heavy since that implies potential disk / network i/o. --Mark -- Mark Fasheh -- 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: Honest timeline for btrfsck
On 10/07/11 04:25, Chester wrote: The problem with this is that people naturally look for a fsck tool when something bad goes wrong. Something as important as a fsck utility shouldn't be released (unofficially or officially) half baked. It can irreparably destroy a filesystem which could've otherwise been repaired with a fully functional fsck. I think Chris is trying to prevent that from happening. What I would like to know instead, is WHY we need an btrfsck when ZFS does not. Zfs also has this kind of problems especially on power failures, but you can always mount by rolling back to a previous uberblock, showing an earlier view of the filesystem, which would be consistent. It wasn't always like this with ZFS, but this feature has been added after ther numerous requests of users who lost their complete filesystems after a power failure or similar events. And there was no zfsck (there still isn't, and it's apparently not needed). This should be the fix I'm talking about (my original link to Sun site doesn't work any more) http://wesunsolve.net/bugid/id/6667683 You can look up the internet with something like zfs roll back txg or zfs mount old uberblock... I don't recall any other I have hosed my FS request for help after the date this feature was implemented/provided. Why isn't this approach dead-easy to implement with btrfs? -- 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: Honest timeline for btrfsck
What I would like to know instead, is WHY we need an btrfsck when ZFS does not. Zfs also has this kind of problems especially on power failures, but you can always mount by rolling back to a previous uberblock, showing an earlier view of the filesystem, which would be consistent. It wasn't always like this with ZFS, but this feature has been added after ther numerous requests of users who lost their complete filesystems after a power failure or similar events. And there was no zfsck (there still isn't, and it's apparently not needed). There's a couple different categories of tool that are occasionally referred to as fsck. Consistency checking (which we already have in the current btrfsck), data recovery (which we have a couple rough tools for, but which improved tools are desired and probably part of cmason's plans), transparent healing making the filesystem always mountable (the big selling point of both zfs and btrfs, although obviously btrfs is still immature in this regard; again, something that progress is expected on), in-place rebuild the world repair tools (which again I believe is part of cmason's plans), online scrubs (which we have), and so on. You'll note that zfs now has all of these tools (and took a remarkable amount of time to acquire some of them), they just never call any combination of them zfsck. Really, zfs doesn't require fsck in exactly the same sense that ext3 doesn't: given hardware that doesn't lie to the filesystem, there's no massive search and rescue operation required after an otherwise unclean shutdown. That's it. And we mostly have that too, modulo the usual and expected bumps of a very young filesystem. --cwillu Warning: cwillu may cause excessive warnings. -- 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: Honest timeline for btrfsck
On Viernes, 7 de Octubre de 2011 21:10:33 Asdo escribió: failures, but you can always mount by rolling back to a previous uberblock, showing an earlier view of the filesystem, which would be consistent. This is already available in Btrfs, command btrfsck -s. -- 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: Honest timeline for btrfsck
Hallo, Asdo, Du meintest am 07.10.11: What I would like to know instead, is WHY we need an btrfsck when ZFS does not. I need at least some tool which can hide defect sectors - I just have such a problem. Viele Gruesse! Helmut -- 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: Honest timeline for btrfsck
Heh, what sort of quality are you thinking would develop? A recovery tool by its nature is picking up the pieces where those pieces are inconsistent. The nature of those inconsistencies will change with every patch that's more than a cleanup. Seriously? You want to delay the solving of the problems we have today, because we are going to have different problems in the future? I hate to be the bearer of bad news, but for the most part, we are going to have new problems in addition to the ones we already have. We are not going to get a whole brand new batch of problems that are somehow going to magically make all our old problems obsolete. You also make the assumption that the solution to these new problems is going to have absolutely no similarity to the current problems, otherwise it would be beneficial to have a quality solution to similar problems to build off of. Combined with the well-known tendencies of users to not report errors that are trivial to work around, and I find myself quite content with the status quo: a few general recovery techniques that can be found with some digging, inconvenient enough that the reports don't get lost, with enough context that the appropriate warnings and alternatives can be given. If the status quo is an acceptable condition, then you must not see the need for any fsck utility. If you see a need for an fsck utility, then certainly you must see the problem in committing to 'eminently' deliver that utility repeatedly for a year or so, and never delivering it. If you don't see that as a fundamental wrench in the works, I don't know what would be. Yes, a deliberately broken-by-makefile version of what he's looking at would be interesting, but I suspect it's not much past what any competent programmer would put together given a couple weeks going over the disk format, and we already have a couple of those. Yeah, I am also suspicious that that is all that exists, and I suspect that may have something to do with the resistance to releasing the source. If that is the case, why not just come clean about it, and let others start contributing, so we can get somewhere with it. What we want is still in Chris' head, otherwise we _would_ have something. If it is still only exists in his head, after a year, how long should we wait before someone else takes the reigns? -- 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
stat returns wrong block count
Hi,
recently I encountered weird (much too small) numbers returned by du. It
turns out that
on some files btrfs returns a wrong number of used blocks.
Two files, identical, non-zero, non-spare:
# ls -l
total 19296 -- block count is wrong, sizes are correct
-rw-r--r-- 1 marc root 19759104 Oct 7 22:55 test.file
-rw-r--r-- 1 marc root 19759104 Oct 7 22:55 test0.file
# du *
19296 test.file
0 test0.file
# cmp test.file test0.file echo identical
identical
# cmp test0.file /dev/zero
test0.file /dev/zero differ: char 3, line 1
from strace -v du
newfstatat(AT_FDCWD, test.file, {..., st_blksize=4096, st_blocks=38592,
st_size=19759104, ...}
newfstatat(AT_FDCWD, test0.file, {..., st_blksize=4096, st_blocks=0,
st_size=19759104, ...}
or
# stat -c %n: %B * %b *
test.file: 512 * 38592
test0.file: 512 * 0
Note that test.file was created by copying test0.file, but using a fresh
copy makes no
difference.
Some bigger files show a block count much too low, but not zero blocks:
# stat -c %n: %B * %b test-big.file
test-big.file: 512 * 276096
# cp test-big.file test-big2.file
# stat -c %n: %B * %b test-big2.file
test-big2.file: 512 * 1074928
The files were originally created by rsync, either over NFSv4 or CIFS (I think
it was CIFS
at first and later switched to NFS) using kernel 3.0.0. Current kernel is
3.1-rc9.
The filesystem is on top of MD-RAID-5. Space cache was not enabled and using
clear_cache or anbling space_cache makes no difference.
Content of the files is completely intact.
Is this a known issue?
Regards,
Marc
--
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
