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 dev` command
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 ka...@wit.edu.pl
diff --git a/utils.c b/utils.c
index ee7fa1b..6773be0 100644
--- a/utils.c
+++ b/utils.c
@@
Signed-off-by: Hubert Kario ka...@wit.edu.pl
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[]
zero_end is set explicitly to 1 inside the fuction so the device end
always will be zeroed out
Signed-off-by: Hubert Kario ka...@wit.edu.pl
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)
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 ka...@wit.edu.pl
Signed-off-by: Hubert Kario ka...@wit.edu.pl
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;
-
On Tue, May 01, 2012 at 02:38:01PM +0200, Hubert Kario wrote:
This patch series adds `btrfs device zero super dev` 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?
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 dev` command to remove
the btrfs signature from the device as well as fix few minor problems in
btrfs_prepare_device function.
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
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 +
commit
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
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 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 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_off,
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
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
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 good FYI
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
On 05/02/2012 06:28 AM, Fajar A. Nugraha wrote:
On Wed, May 2, 2012 at 9:22 AM, Bardur Arantssons...@scientician.net wrote:
On 05/01/2012 09:35 PM, Martin wrote:
From Kconfig:
Btrfs filesystem (EXPERIMENTAL) Unstable disk format
^^
19 matches
Mail list logo
