I see the filesystem going readonly when run_clustered_refs returns
-ENOSPC [1], so it looks like we need something like:
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2451,7 +2451,8 @@ again:
ret = run_clustered_refs(trans, root, &cluster);
if (ret
On Wed, May 2, 2012 at 12:00 PM, Bardur Arantsson wrote:
> On 05/02/2012 06:28 AM, Fajar A. Nugraha wrote:
>>> From Kconfig:
>>>
>>> "Btrfs filesystem (EXPERIMENTAL) Unstable disk format"
>>> ^^
>>>
>>> Btrfs is too immature to use in ANY kin
On 05/02/2012 06:28 AM, Fajar A. Nugraha wrote:
On Wed, May 2, 2012 at 9:22 AM, Bardur Arantsson wrote:
On 05/01/2012 09:35 PM, Martin wrote:
From Kconfig:
"Btrfs filesystem (EXPERIMENTAL) Unstable disk format"
^^
Btrfs is too immat
On Wed, May 2, 2012 at 9:22 AM, Bardur Arantsson wrote:
> On 05/01/2012 09:35 PM, Martin wrote:
>>
>> How well does btrfs perform across a mix of:
>>
>> 1 SSD and 1 HDD for 'raid' 1 mirror for both data and metadata?
>> The idea is to gain the random access speed of the SSDs but have the
>> HDDs
On 05/01/2012 09:35 PM, Martin wrote:
How well does btrfs perform across a mix of:
1 SSD and 1 HDD for 'raid' 1 mirror for both data and metadata?
Similarly so across 2 SSDs and 2 HDDs (4 devices)?
Can multiple (small) SSDs be 'clustered' as one device and then mirrored
with one large HDD with
On 01/05/12 22:16, sam tygier wrote:
> On 01/05/12 20:35, Martin wrote:
>
>> The idea is to gain the random access speed of the SSDs but have the
>> HDDs as backup in case the SSDs fail due to wear...
>
> Have you looked at the bcache project http://bcache.evilpiepirate.org/
Many thanks for that
On 02/05/12 00:18, Martin wrote:
> How well suited is btrfs to low-end and high-end FLASH devices?
>
>
> Paraphrasing from a thread elsewhere:
>
> FLASH can be categorised into two classes, which have extremely
> different characteristics:
>
> (a) the low-end (USB, SDHC, CF, cheap ATA SSD);
A
How well suited is btrfs to low-end and high-end FLASH devices?
Paraphrasing from a thread elsewhere:
FLASH can be categorised into two classes, which have extremely
different characteristics:
(a) the low-end (USB, SDHC, CF, cheap ATA SSD);
and (b) the high-end (SAS, PCIe, NAS, expensive ATA S
On 01/05/12 20:35, Martin wrote:
The idea is to gain the random access speed of the SSDs but have the
HDDs as backup in case the SSDs fail due to wear...
Have you looked at the bcache project http://bcache.evilpiepirate.org/
sam
--
To unsubscribe from this list: send the line "unsubscribe li
How well does btrfs perform across a mix of:
1 SSD and 1 HDD for 'raid' 1 mirror for both data and metadata?
Similarly so across 2 SSDs and 2 HDDs (4 devices)?
Can multiple (small) SSDs be 'clustered' as one device and then mirrored
with one large HDD with btrfs directly? (Other than using lvm..
On Thu, Apr 12, 2012 at 05:53:15PM +0200, Jan Schmidt wrote:
> Hi Mark,
>
> While reading 3/3 I stumbled across one more thing in this one:
>
> On 05.04.2012 22:09, Mark Fasheh wrote:
> > +int btrfs_find_one_extref(struct btrfs_root *root, u64 inode_objectid,
> > + u64 start_o
On Tuesday 01 of May 2012 18:04:25 Martin wrote:
> Are 16kByte blocks/sectors useful to btrfs?
>
> Or rather, can btrfs usefully use 16kByte blocks?
Yes, and they are already supported using -l and -n flags:
mkfs.btrfs -l $((4*4096)) -n $((4*4096)) /dev/sda1
You can set sector size to 16kb but
On Thursday 29 of March 2012 09:24:44 Liu Bo wrote:
> On 03/29/2012 12:54 AM, Goffredo Baroncelli wrote:
> > Could you elaborate which would be the issue ?
> > "cp --reflink"-ing a file is not different than snapshotting a file. In
> > any case I could mount a snapshot and not the source subvolume.
Looking at this again from some time ago...
Brief summary:
There is a LOT of nefarious cleverness being attempted by SSD
manufacturers to accommodate a 4kByte block size. Get that wrong, or
just be unsympathetic to that 'cleverness', and you suffer performance
degradation and/or premature device
On 05/01/2012 10:00 AM, Josef Bacik wrote:
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
On 04/11/2012 01:09 PM, Josef Bacik wrote:
On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
Hi,
I hit this BUG today.
I'm running 3.3.1 merged with the ceph and btrfs bits for 3.
On Wed, Apr 11, 2012 at 02:24:30PM -0600, Jim Schutt wrote:
> On 04/11/2012 01:09 PM, Josef Bacik wrote:
> >On Tue, Apr 10, 2012 at 01:39:14PM -0600, Jim Schutt wrote:
> >>Hi,
> >>
> >>I hit this BUG today.
> >>
> >>I'm running 3.3.1 merged with the ceph and btrfs bits for 3.4,
> >>i.e. 3.3.1 +
> >
If we happen to alloc a extent buffer and then alloc a page and notice that
page is already attached to an extent buffer, we will only unlock it and
free our existing eb. Any pages currently attached to that eb will be
properly freed, but we don't do the page_cache_release() on the page where
we n
On Tuesday 01 of May 2012 14:43:37 Tomasz Torcz wrote:
> On Tue, May 01, 2012 at 02:38:01PM +0200, Hubert Kario wrote:
> > This patch series adds `btrfs device zero super ` command to remove
> > the btrfs signature from the device as well as fix few minor problems in
> > btrfs_prepare_device functi
On Tue, May 01, 2012 at 02:38:01PM +0200, Hubert Kario wrote:
> This patch series adds `btrfs device zero super ` command to remove the
> btrfs signature from the device as well as fix few minor problems in
> btrfs_prepare_device function.
Shouldn't you rather extend “wipefs” from util-linux?
-
Signed-off-by: Hubert Kario
diff --git a/cmds-device.c b/cmds-device.c
index a28752f..b1e70f9 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -261,8 +261,6 @@ static int cmd_zero_dev(int argc, char **argv)
int arg_processed;
int ret = 0;
int n;
- u64 device_len;
-
btrfs_prepare_device did abort the whole application on any error,
even when there were other tasks queued that could succeed, now it
returns non zero value on error.
Add more descriptive error messages: print failing device name and
cause of error.
Signed-off-by: Hubert Kario
diff --git a/mkfs
zero_end is set explicitly to 1 inside the fuction so the device end
always will be zeroed out
Signed-off-by: Hubert Kario
diff --git a/btrfs-vol.c b/btrfs-vol.c
index 0efdbc1..c7b9f80 100644
--- a/btrfs-vol.c
+++ b/btrfs-vol.c
@@ -150,7 +150,7 @@ int main(int ac, char **av)
if (cmd == B
Signed-off-by: Hubert Kario
diff --git a/cmds-device.c b/cmds-device.c
index db625a6..05a549c 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -246,11 +246,58 @@ static int cmd_scan_dev(int argc, char **argv)
return 0;
}
+static const char * const cmd_zero_dev_usage[] = {
+ "btr
When calling the function from `btrfs device zero-super` we don't need
the additional information returned and don't want the "SMALL VOLUME"
warning printed.
Signed-off-by: Hubert Kario
diff --git a/utils.c b/utils.c
index ee7fa1b..6773be0 100644
--- a/utils.c
+++ b/utils.c
@@ -557,7 +557,7 @@ i
If there is a btrfs created on a raw block device (raw disk) and later there
are created partitions and btrfs file systems created on partitions, subsequent
`btrfs device scan` won't remove the btrfs signature from the raw block device.
This patch series adds `btrfs device zero super ` command to
25 matches
Mail list logo