could i-node numbers be made unique on a whole device, or somehow
adjusted to avoid collisions, instead of simply disallowing this
useful operation?
On Thu, Oct 7, 2010 at 4:13 PM, Goffredo Baroncelli kreij...@libero.it wrote:
The link across subvolumes is not allowable. In the beginning it
On Thu, Oct 07, 2010 at 11:13:18PM +0200, Goffredo Baroncelli wrote:
On Thursday, 07 October, 2010, David Nicol wrote:
On Thu, Oct 7, 2010 at 8:18 AM, Mike Hommey m...@glandium.org wrote:
BTW, it would be very useful to be able to turn existing directories
into subvolumes.
does a
On Fri, Oct 8, 2010 at 11:00 PM, Evert Vorster evors...@gmail.com wrote:
Hi there...
I'm not an expert. however, since you don't care about the data on
the SSD anymore, reformat it, and fill it up, then verify what you
have written.
However, if the capacity has changed, would that not
Hi, this is my first post and contribution to Btrfs.
I wrote a documentation on how to debug Btrfs with GDB on UML(User Mode Linux).
https://btrfs.wiki.kernel.org/index.php/Debugging_Btrfs_with_GDB
This document might be little bit boring for Btrfs hackers,
but for beginners who want to join
Gerhard Kulzer gerhard at kulzer.net writes:
Chris Mason chris.mason at oracle.com writes:
[7.881078] Btrfs detected SSD devices, enabling SSD mode
[7.923553] [ cut here ]
[7.923556] kernel BUG at /build/buildd/linux-2.6.35/fs/btrfs
On Saturday, 09 October, 2010, you (David Nicol) wrote:
could i-node numbers be made unique on a whole device, or somehow
adjusted to avoid collisions, instead of simply disallowing this
useful operation?
In case of a snapshot make sense to preserve the inode number.
On Thu, Oct 7, 2010 at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Today I pulled btrfs-progs-unstable from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
and I found the patch from below still not applied. Is there a reason
for this?
Regards,
Andreas Philipp
On 13.09.2010
On Saturday, 09 October, 2010, you (Mike Hommey) wrote:
On Thu, Oct 07, 2010 at 11:13:18PM +0200, Goffredo Baroncelli wrote:
On Thursday, 07 October, 2010, David Nicol wrote:
On Thu, Oct 7, 2010 at 8:18 AM, Mike Hommey m...@glandium.org wrote:
BTW, it would be very useful to be able to
I've just encountered some odd behaviour with regard to removed
devices. Brief summary:
- It's hard (in some sense) to tell a btrfs filesystem that a device
has been removed permanently, and seems to require an
unmount/remount, or resize to do so.
- Removed devices break btrfs dev
On 13.09.2010 21:23, Goffredo Baroncelli wrote:
Hi all,
enclose you can find a patch which improve the help of the btrfs
commands and its man page. Regarding the help of the btrfs
command: - moved the subvolume set-default command in the
subvolume commands group - removed a wrong new line
when i have some time to work on this I will figure out a way to pull
inodes from a larger pool or include the subvolume id at creation time
in them or something so that the collisions go away. Surely it must be
possible to prefix or suffix the inode number with a few bits that are
per-subvolume
Hi all,
enclose you can find a patch which improves the help of the btrfs commands,
updates the INSTALL file and the btrfs (command) man page.
Regarding the help of the btrfs command:
- moved the subvolume set-default command in the subvolume commands group
- removed a wrong new line
Hi Hugo,
I can reproduce this behavior, and the solution is quite simple: do a sync
after the removing the device.
Let me explain what (I think) happen.
The command btrfs filesystem show reads every block device and shows the
relevant information. This is performed without passing for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I tried the patch and found a few more things one might to
update/clean up.
Regarding the INSTALL file:
- - There are three example lines for snapshot creation while two can
show the same things.
Regarding the help of the btrfs command:
-
14 matches
Mail list logo
