Creating snapshot passes extent_root to commit its transaction,
but it can lead to the warning of checking root for quota in
the __btrfs_end_transaction() when someone else is committing
the current transaction. Since we've recorded the needed root
in trans_handle, just use it to get rid of the
I've missed an important detail in the reproducer, sorry
On Wed, Mar 06, 2013 at 04:56:40PM +0100, David Sterba wrote:
Reproducer:
$ mfks.btrfs /dev/sda
$ mount /dev/sda /mnt
$ btrfs scrub start /mnt
sleep 5
$ btrfs scrub status /mnt
... super:2 ...
otherwise the scrub status is not
Am 04.03.2013 00:52, schrieb Chris Mason:
On Sun, Mar 03, 2013 at 06:57:41AM -0700, Michael Schmitt wrote:
Hi list,
some rather unexpected btrfs-oopses for my taste. I use btrfs for some
time now (mostly on external harddisks) and these oopses happened
during some simple file and folder
On Wed, Mar 06, 2013 at 10:12:11PM -0500, Chris Mason wrote:
Also, I want to ask, hope this is not inappropriate. Do you also agree
with Josef, that it's ok for BTRFS_IOC_SNAP_DESTROY not to commit the
transaction, but just to detach from it? Had we committed, we would
have ensured
Hi,
mkfs.btrfs v0.20-rc1, as provided in the excellent Parted Magic tool,
latest version dated 2013/02/28, is broken :
When trying to mkfs.btrfs - even on newly made, FS-free partition, it
always spits an error that it cannot check partition mount status and fails.
There has always been such an
On 3/7/13 6:11 AM, Swâmi Petaramesh wrote:
Hi,
mkfs.btrfs v0.20-rc1, as provided in the excellent Parted Magic tool,
latest version dated 2013/02/28, is broken :
Unfortunately v0.20-rc1 spans months of development, since btrfs-progs
has no consistent release or versioning activity.
When
On Wed, Mar 06, 2013 at 10:57:55AM +0200, Ilya Dryomov wrote:
Raid56 merge (merge commit e942f88) had mistakenly removed a call to
__cancel_balance(), which resulted in balance not cleaning up after itself
after a successful finish. (Cleanup includes switching the state, removing
the balance
On 03/07/2013 08:11 PM, Swâmi Petaramesh wrote:
Hi,
mkfs.btrfs v0.20-rc1, as provided in the excellent Parted Magic tool,
latest version dated 2013/02/28, is broken :
When trying to mkfs.btrfs - even on newly made, FS-free partition, it
always spits an error that it cannot check partition
Hi,
I'm seeing messages like this
[ 3194.928153] btrfs allocation failed flags 1, wanted 65536
[ 3194.934874] space_info 1 has 147456 free, is full
[ 3194.941205] space_info total=1903427584, used=1903280128, pinned=0,
reserved=0, may_use=65536, readonly=0
[ 3194.941209] block group 12582912
[resent with subject]
Hi,
I'm seeing messages like this
[ 3194.928153] btrfs allocation failed flags 1, wanted 65536
[ 3194.934874] space_info 1 has 147456 free, is full
[ 3194.941205] space_info total=1903427584, used=1903280128, pinned=0,
reserved=0, may_use=65536, readonly=0
[ 3194.941209]
On Wed, Mar 06, 2013 at 10:56:37AM -0800, Zach Brown wrote:
+static int btrfs_check_super_csum(char *raw_disk_sb)
I'd have it return 0 or -errno and print warnings with additional info
so that each caller doesn't have to.
What errno values do you suggest? For me it's 'checksum is correct:
Le 07/03/2013 14:37, Eric Sandeen a écrit :
What error messages does it emit, anything helpful?
root@partedmagic:~# file -s /dev/sda5
/dev/sda5: data
root@partedmagic:~# mkfs.btrfs /dev/sda5
WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using
On 3/7/13 9:09 AM, Swâmi Petaramesh wrote:
Le 07/03/2013 14:37, Eric Sandeen a écrit :
What error messages does it emit, anything helpful?
root@partedmagic:~# file -s /dev/sda5
/dev/sda5: data
root@partedmagic:~# mkfs.btrfs /dev/sda5
WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL
Le 07/03/2013 16:13, Eric Sandeen a écrit :
# strace -o tracefile.txt mkfs.btrfs /dev/sda5 tracefile.txt will
contain all syscalls made by the binary and their results, which might
give us a clue what's gone wrong. -Eric
Here it goes !
execve(/sbin/mkfs.btrfs, [mkfs.btrfs, /dev/sda5], [/* 28
On Thu, Mar 07, 2013 at 08:21:51AM -0700, Swâmi Petaramesh wrote:
Le 07/03/2013 16:13, Eric Sandeen a écrit :
# strace -o tracefile.txt mkfs.btrfs /dev/sda5 tracefile.txt will
contain all syscalls made by the binary and their results, which might
give us a clue what's gone wrong. -Eric
Le 07/03/2013 16:35, Chris Mason a écrit :
Could you please send the contents of /proc/mounts
Here it goes !
(Last line is the USB key I dropped in just for taking a copy of
/proc/mounts ; it didn't exist at the time the errors occured...)
rootfs / rootfs rw 0 0
proc /proc proc rw,relatime 0 0
On Wed, Mar 06, 2013 at 10:53:22PM -0700, Miao Xie wrote:
Onwed, 6 Mar 2013 22:06:50 -0500, Chris Mason wrote:
On Wed, Mar 06, 2013 at 06:39:30PM -0700, Miao Xie wrote:
On wed, 6 Mar 2013 09:53:28 -0500, Chris Mason wrote:
[SNIP]
+ async_work-delayed_root = delayed_root;
+
What errno values do you suggest? For me it's 'checksum is correct:
yes/no', hence return 1/0.
Oh, I have no strong preerence here.
I see an -EIO below, but that does not seem right here. There's a call
to btrfs_read_dev_super that would indicate an unreadable block. We
could use
hi
I am using compression lzo on my 350GB partition, I have 2 subvolumes
on this partition. My kernel is 3.7 BTRFS v0.19 -
According to my system (df -h) that partition has 75Gb available.
According to btrfs
btrfs fi df /mnt/DevSystem/
Data: total=260.01GB, used=259.09GB
System, DUP:
On Thu, Mar 7, 2013 at 10:21 AM, Swâmi Petaramesh sw...@petaramesh.org wrote:
lstat64(/sqfs_disk, 0xbff57820) = -1 ENOENT (No such file or
directory)
mkfs.btrfs tries to lookup loop devices by their filenames and fails
if any loop device file is missing.
--
To unsubscribe from this list:
Le 07/03/2013 19:06, Jérôme Poulin a écrit :
mkfs.btrfs tries to lookup loop devices by their filenames and fails
if any loop device file is missing.
Hmm Why would mkfs.btrfs want to lookup anything else but the device
we're trying to format, to check if it's mounted or not ?
--
Swâmi
We currently store the first key of the tree block inside the reference for the
tree block in the extent tree. This takes up quite a bit of space. Make a new
key type for metadata which holds the level as the offset and completely removes
storing the btrfs_tree_block_info inside the extent ref.
This fixes up the progs to properly deal with skinny metadata. This adds the -x
option to mkfs and btrfstune for enabling the skinny metadata option. This also
makes changes to fsck so it can properly deal with the skinny metadata entries.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
+static inline int btrfs_fs_incompat(struct btrfs_fs_info *fs_info, u64 flag)
+{
+ struct btrfs_super_block *disk_super;
+ disk_super = fs_info-super_copy;
+ return (btrfs_super_incompat_flags(disk_super) flag);
+}
That'll fail if there are ever flag bits that don't fit in an
It looks like [1] and [2] didn't make it into 3.8 and are not in 3.8.2,
nor the queue [3]. Can somebody forward them to stable, if they are
appropriate? I think these are the proper commits:
925396e Btrfs: account for orphan inodes properly during cleanup
4a7d0f6 Btrfs: cleanup orphan
On Thu, Mar 7, 2013 at 11:05 AM, Steve Heyns notzi...@gmail.com wrote:
hi
I am using compression lzo on my 350GB partition, I have 2 subvolumes
on this partition. My kernel is 3.7 BTRFS v0.19 -
According to my system (df -h) that partition has 75Gb available.
According to btrfs
btrfs fi
# btrfs fi show /dev/sda1
Label: 'DevSystem_Backup' uuid: e781af8b-bc92-4fc3-aeb9-b21712bcadf9
Total devices 1 FS bytes used 134.48GB
devid1 size 350.00GB used 276.04GB path /dev/sda1
thanks
On Thu, Mar 7, 2013 at 12:50 PM, cwillu cwi...@cwillu.com wrote:
btrfs fi show
On Thu, Mar 07, 2013 at 12:50:42PM -0700, Zach Brown wrote:
+static inline int btrfs_fs_incompat(struct btrfs_fs_info *fs_info, u64
flag)
+{
+ struct btrfs_super_block *disk_super;
+ disk_super = fs_info-super_copy;
+ return (btrfs_super_incompat_flags(disk_super) flag);
+}
On Thu, Mar 7, 2013 at 12:10 PM, Swâmi Petaramesh sw...@petaramesh.org wrote:
Le 07/03/2013 19:06, Jérôme Poulin a écrit :
mkfs.btrfs tries to lookup loop devices by their filenames and fails
if any loop device file is missing.
Hmm Why would mkfs.btrfs want to lookup anything else but the
On Thu, Mar 07, 2013 at 02:27:57PM -0500, Josef Bacik wrote:
+ /*
+ * If we don't have skinny metadata, don't bother doing anything
+ * different
+ */
+ if (metadata
+ !btrfs_fs_incompat(root-fs_info,
+
On Thu, Mar 07, 2013 at 02:27:57PM -0500, Josef Bacik wrote:
We currently store the first key of the tree block inside the reference for
the
tree block in the extent tree. This takes up quite a bit of space. Make a
new
key type for metadata which holds the level as the offset and
On Thu, Mar 07, 2013 at 04:29:18PM -0500, Josef Bacik wrote:
The searches do different things in different places so we have to have samey
blobs like this until we get everybody on skinny metadata and can delete the
old
code. Thanks,
History says that once you have a disk format out in the
32 matches
Mail list logo
