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 t
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 comp
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,
> +BTRFS_FEATURE_INCOMP
On Thu, Mar 7, 2013 at 12:10 PM, Swâmi Petaramesh 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 device
> we'r
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)
# 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 wrote:
> btrfs fi show /dev/
--
To unsubs
On Thu, Mar 7, 2013 at 11:05 AM, Steve Heyns 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 df /mnt/Dev
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 reserva
> +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
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
---
btrfstune.c |
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.
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 Pe
On Thu, Mar 7, 2013 at 10:21 AM, Swâmi Petaramesh 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: send the line "un
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: total=8.00M
> 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 EFSCOR
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;
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 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. -Eri
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"],
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 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
e
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 correc
[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] bl
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 has
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
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 balan
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.
>
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 a
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
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 delet
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
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 wa
32 matches
Mail list logo
