Re: unlink directory with files (rm -d)
I wonder if it would be possible to implement instant unlinking directory with files in it. Since btrfs is based on b trees it could be possible. Filesystem would have to loose all information on directory and object in it, and allow overwriting this information. This would be great feature, because everyone knows that recursive deleting large directories, with milions of files require huge io traffic. I think you'll have to read directory contents anyway in order not to break permission/vfs-mountpoint/attributes violation. Consider the following example: # it's me $ id uid=1000(slyfox) gid=100(users) # fun layout $ ls -ld test test/root_o test/root_o/root_o drwxr-xr-x 3 slyfox users 60 Aug 14 10:56 test drwxr-xr-x 2 root root 60 Aug 14 10:56 test/root_o -rw-r--r-- 1 root root 0 Aug 14 10:56 test/root_o/root_o $ rm -rf test/ rm: cannot remove `test/root_o/root_o': Permission denied We can't delete it because of foreigner in our dir. -- Sergei signature.asc Description: PGP signature
btrfs: failed to read chunk root
Hello, trying out btrfs on my linux installation. I am running Funtoo with Linux 3.0 kernel. After a reboot kernel panicked (no access to error log since it is my root volume that failed). I get this using a rescue cd (2.6.38, btrfs v 0.19) and then trying to mount : [ 752.129118] btrfs bad tree block start 0 131072 [ 752.129152] btrfs: failed to read chunk root on sda5 [ 752.132190] btrfs: open_ctree failed [ 1132.984600] device label deux devid 1 transid 86 /dev/sdb3 [ 1171.796682] device fsid 9d42de57e2bebde7-4824b05acb3c538d devid 1 transid 346 /dev/sda5 Trying btrfsck: btrfsck: disk-io.c:721: open_ctree_fd: Assertion `!(!chunk_root-node)' failed. It had worked alright during the last couple of reboots. Before rebooting I created a new btrfs volume which I am able to mount without problems in rescue mode. Thanks for any help, Espen -- 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: corrupted btrfs volume: parent transid verify failed
Halp! I was recently forced to power cycle my desktop PC, and upon restart, the btrfs /home volume would no longer mount, citing the error BUG: scheduling while atomic: mount /5584/0x2. I retrieved the latest btrfs-progs git repositories from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git and http://git.darksatanic.net/repo/btrfs-progs-unstable.git -b integration-20110805, but when running sudo ./btrfsck -s 1 /dev/mapper/home from either repo builds, I receive the error parent transid verify failed on 647363842048 wanted 210333 found 210302 (repeated 3x). I've also tried the flags -s 0, -s 1, and -s 2, all with the same results. I take care to complete a full dd copy of my disk every 2 weeks, but my previous backup is nearly 2 weeks old and I've put in almost 2 weeks of effort on my masters thesis since then. I'm quite desperate to recover this volume. Any help is appreciated, as I've exhausted the existing suggestions from the mailing list posts to date. I've tried to ask in #btrfs, but suspect that they're all sleepy bearded people :( Regards, -Yalonda -- 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: corrupted btrfs volume: parent transid verify failed
On Mon, Aug 15, 2011 at 4:13 AM, Yalonda Gishtaka yalonda.gisht...@gmail.com wrote: Halp! I was recently forced to power cycle my desktop PC, and upon restart, the btrfs /home volume would no longer mount, citing the error BUG: scheduling while atomic: mount /5584/0x2. I retrieved the latest btrfs-progs git repositories from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git and http://git.darksatanic.net/repo/btrfs-progs-unstable.git -b integration-20110805, but when running sudo ./btrfsck -s 1 /dev/mapper/home from either repo builds, I receive the error parent transid verify failed on 647363842048 wanted 210333 found 210302 (repeated 3x). I've also tried the flags -s 0, -s 1, and -s 2, all with the same results. Is there something in the log about replaying log? If yes, try btrfs-zero-log https://btrfs.wiki.kernel.org/index.php/Problem_FAQ -- Fajar -- 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: corrupted btrfs volume: parent transid verify failed
Fajar, Thank you for the suggestion. Unfortunately, running sudo ./btrfs-zero-log /dev/mapper/home results in the same parent transid verify failed on 647363842048 wanted 210333 found 210302 errors, repeated 3 times. I am running Arch Linux with the latest 3.0.1 kernel on a x86_64 machine. Regards, -Yalonda On Sun, Aug 14, 2011 at 11:40 PM, Fajar A. Nugraha l...@fajar.net wrote: On Mon, Aug 15, 2011 at 4:13 AM, Yalonda Gishtaka yalonda.gisht...@gmail.com wrote: Halp! I was recently forced to power cycle my desktop PC, and upon restart, the btrfs /home volume would no longer mount, citing the error BUG: scheduling while atomic: mount /5584/0x2. I retrieved the latest btrfs-progs git repositories from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git and http://git.darksatanic.net/repo/btrfs-progs-unstable.git -b integration-20110805, but when running sudo ./btrfsck -s 1 /dev/mapper/home from either repo builds, I receive the error parent transid verify failed on 647363842048 wanted 210333 found 210302 (repeated 3x). I've also tried the flags -s 0, -s 1, and -s 2, all with the same results. Is there something in the log about replaying log? If yes, try btrfs-zero-log https://btrfs.wiki.kernel.org/index.php/Problem_FAQ -- Fajar -- 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: corrupted btrfs volume: parent transid verify failed
Soon seems a bit subjective given that the devs have been touting this since the beginning of time. /Helpful/ advice would be nice. This blog posting (http://stujordan.wordpress.com/2011/06/20/churning-the-butter/) sounded promising, but none of the superblock copies on my btrfs volume are ok, as I keep receiving the same parent transid verify failed messages. Will be released btrfsck tool handle this case? On Mon, Aug 15, 2011 at 1:10 AM, Michael Cronenworth m...@cchtml.com wrote: On 08/14/2011 04:13 PM, Yalonda Gishtaka wrote: I'm quite desperate to recover this volume. You should have had backups. Btrfs has no file system repair tool, but it is supposed to be out soon (tm). You will have to wait. -- 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: corrupted btrfs volume: parent transid verify failed
Telling someone (that has a ~2 week stale backup) that they should have kept backups is hardly constructive. We're all aware there's no official btrfs repair tool. But it appears there has been been some hard, dedicated work towards this that has resulted in many commits and patches. I'm here to find out what there is to know about recent developments that may help my current situation. Please consider offering helpful advice instead of pointing out the obvious about my backup schedule. Cheers, -Yalonda On Mon, Aug 15, 2011 at 1:51 AM, Michael Cronenworth m...@cchtml.com wrote: On 08/14/2011 06:32 PM, Yalonda Gishtaka wrote: /Helpful/ advice would be nice. Being hostile will net you zero advice. -- 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
licenses (for apple OSX and others)?
curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? as end users, having one good file system that works everywhere as a main root system would be heaven... -- 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: licenses (for apple OSX and others)?
From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- ow...@vger.kernel.org] On Behalf Of ivo welch curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? No. The source code is copyrighted by many different entities, and the only way to release it under any other license would require all of the contributors to mutually agree. It'll never happen. Likewise, perhaps Apple could release their code under a license that's compatible with GPL, but I seriously doubt that would ever happen. as end users, having one good file system that works everywhere as a main root system would be heaven... Agreed. But the various producers of filesystems are generally commercial entities interested in making a profit. For various reasons, many of them intentionally don't go this direction. They're all trying to differentiate themselves. Generally speaking, the problem is the requirement to integrate some other FS into a kernel or other component that requires license compatibility for booting. Generally speaking you can circumvent this problem by using things like Fuse to mount a filesystem in user space, thus not requiring it to be built into the kernel, thus eliminating any license compatibility problems. -- 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: licenses (for apple OSX and others)?
thx, ed. this is a case where I am wondering whether EVERYONE, including all the commercial contributors to btrfs, would be better off with another additional license that also allowed kernel integration for companies like Apple. the decision-making (and rights) for btrfs are so dispersed, however, that we may all end up with a worse outcome, including the commercial and other contributors. (perhaps, it would be worth asking them, if a mailing list of contributors to btrfs existed.) I am and I am not a fan of Apple. they scare me. I am afraid that Apple will be much worse than IBM and Microsoft ever were. I would rather not see them get more than 20% market share. still, the world is what it is. now, specifically, which contributors to btrfs would it hurt if Apple were allowed to integrate the code into its kernel to make btrfs its main file system? I can only think of Microsoft as a company that might be hurt. FAT is the universal file system now, and it could lose that status. Microsoft may not have wanted to contribute to btrfs in this case to begin with. did they ever contribute here? I cannot imagine that any server company, like Sun, Oracle, or IBM, would be worse off if OSX and linux would both use btrfs. it would probably make their life a whole lot easier. linux on the desktop would be MUCH better off compared to the current situation with everyone using their own almost-compatible file system, and more so than OSX on the desktop would be better off. (linux on the server would probably be mildly better off, but here one can argue that Apple would get more than it contributes.) besides, the btrfs system would control the evolution of btrfs, not Apple. just my two cents... /iaw On Sun, Aug 14, 2011 at 7:00 PM, Edward Ned Harvey ker...@nedharvey.com wrote: From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- ow...@vger.kernel.org] On Behalf Of ivo welch curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? No. The source code is copyrighted by many different entities, and the only way to release it under any other license would require all of the contributors to mutually agree. It'll never happen. Likewise, perhaps Apple could release their code under a license that's compatible with GPL, but I seriously doubt that would ever happen. as end users, having one good file system that works everywhere as a main root system would be heaven... Agreed. But the various producers of filesystems are generally commercial entities interested in making a profit. For various reasons, many of them intentionally don't go this direction. They're all trying to differentiate themselves. Generally speaking, the problem is the requirement to integrate some other FS into a kernel or other component that requires license compatibility for booting. Generally speaking you can circumvent this problem by using things like Fuse to mount a filesystem in user space, thus not requiring it to be built into the kernel, thus eliminating any license compatibility problems. -- 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: licenses (for apple OSX and others)?
On Sun, Aug 14, 2011 at 19:34, ivo welch ivo...@gmail.com wrote: curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? Great question, Ivo. And it turns out, btrfs is already licensed to permit commercial use, integration into other products, and resale. The license of btrfs isn't stopping Apple or Microsoft from using btrfs. All licenses have terms (You should read the terms on some of Apple and Microsoft's software), but so long as they don't violate any terms, they are welcome to use all parts of the btrfs code for their corporation's profit, and their customer's benefit. -- 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: licenses (for apple OSX and others)?
On Sun, Aug 14, 2011 at 9:53 PM, Billy Crook billycr...@gmail.com wrote: On Sun, Aug 14, 2011 at 19:34, ivo welch ivo...@gmail.com wrote: curiosity question---could btrfs be licensed in multiple ways to allow Apple and other vendors to adopt it? Great question, Ivo. And it turns out, btrfs is already licensed to permit commercial use, integration into other products, and resale. The license of btrfs isn't stopping Apple or Microsoft from using btrfs. All licenses have terms (You should read the terms on some of Apple and Microsoft's software), but so long as they don't violate any terms, they are welcome to use all parts of the btrfs code for their corporation's profit, and their customer's benefit. ... and while some will certainly argue one way or another, this is a case where (IMO) the code for btrfs (as a module) is clearly distinct from the OSX kernel (as it was not even designed for it originally) and would not constitute far reaching public release of Apple IP ... though tbh i know nothing about OSX kernel and whether it support things like dynamic modules, so i could be mistaken ... ... but im confident there is a way Apple could wire it up so IP release could be very small or nonexistent. or maintain a port if they so wished. the real question is whether or not they would even desire using it with infrastructure around HFS+/etc ... in my observations Apple and friends are incredibly ... ehm ... selective -- the hardware and everything above it *must* have the `Seal of Approval` -- maybe to reduce/isolate their problem pool or maintain it's clique-crazed chic aura :-), i dont know, but it's not for the end-user's flexibility -- that's for sure. the glaring example to me is virtually the entire mobile/handheld/device industry deciding on micro-USB as the power+data xchange connection *except* one infamous product line ... but meh, who really knows anyway; it certainly would be incredibly cool to have a common denominator greater than FAT, especially since commodity flash chips are 8-16GB now. -- C Anthony -- 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
