On Tue, Oct 21, 2014 at 03:19:09PM -0400, Chris Mason wrote:
On Mon, Oct 20, 2014 at 6:12 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 20, 2014 at 01:22:22PM +0100, Filipe Manana wrote:
May I suggest porting the following commit to 3.14 too?
Goffredo Baroncelli posted on Tue, 21 Oct 2014 18:40:19 +0200 as
excerpted:
On 10/21/2014 11:50 AM, Duncan wrote:
Goffredo Baroncelli posted on Mon, 20 Oct 2014 22:21:04 +0200 as
excerpted:
[...]
Could this be related to the inode overflow in 32 bit system (see
inode_cache options) ?
But 5000 snapshots?
Why? Are you *TRYING* to test btrfs until it breaks, or TRYING to
demonstrate a balance taking an entire year?
Remember a given btrfs filesystem is not necessarily a backup
destination for data from one source.
It can be, say, 30 or 60 daily snapshots, plus several
Tomasz Chmielewski posted on Wed, 22 Oct 2014 09:14:14 +0200 as excerpted:
Remember a given btrfs filesystem is not necessarily a backup
destination for data from one source.
It can be, say, 30 or 60 daily snapshots, plus several monthly, for each
data source * number of data sources.
So
Hi,
You have mentioned two issues when balance and fi show running
concurrently
- stalling and
- errors.
first of all..
3.17 replaced our own system wide disk scan methods by lblkid scan
methods. lblkid with its feature-rich is slower as reported here.
This is just a clean up patch which looks like you have missed
it in 3.17. sorry if it confused you.
On 10/07/14 08:08, Anand Jain wrote:
After Patch:
remove BTRFS_SCAN_PROC scan method
There isn't any consumer for btrfs_scan_block_devices() so delete it.
Signed-off-by: Anand Jain
On 2014-10-21 16:44, Arnaud Kapp wrote:
Hello,
I would like to ask if the balance time is related to the number of
snapshot or if this is related only to data (or both).
I currently have about 4TB of data and around 5k snapshots. I'm thinking
of going raid1 instead of single. From the numbers
On 2014-10-21 21:10, Robert White wrote:
I don't think balance will _ever_ move the contents of a read only
snapshot. I could be wrong. I think you just end up with an endlessly
fragmented storage space and balance has to take each chunk and search
for someplace else it might better fit. Which
On 22.10.2014 03:43, Chris Murphy wrote:
On Oct 21, 2014, at 4:14 PM, Piotr Pawłowp...@siedziba.pl wrote:
Looks normal to me. Last time I started a balance after adding 6th device to my
FS, it took 4 days to move 25GBs of data.
It's long term untenable. At some point it must be fixed. It's
On Tue, Oct 21, 2014 at 10:08 PM, Duncan 1i5t5.dun...@cox.net wrote:
As for the mounted filesystem question, since all it does is flip a
switch so that new metadata writes use the skinny-metadata code path, it
shouldn't be a problem.
Nope. Just tried it here:
# btrfs --version
Btrfs
On Oct 21, 2014, at 9:43 PM, Chris Murphy li...@colorremedies.com wrote:
On Oct 21, 2014, at 4:14 PM, Piotr Pawłow p...@siedziba.pl wrote:
On 21.10.2014 20:59, Tomasz Chmielewski wrote:
FYI - after a failed disk and replacing it I've run a balance; it took
almost 3 weeks to complete,
On 22/10/2014 14:40, Piotr Pawłow wrote:
On 22.10.2014 03:43, Chris Murphy wrote:
On Oct 21, 2014, at 4:14 PM, Piotr Pawłowp...@siedziba.pl wrote:
Looks normal to me. Last time I started a balance after adding 6th
device to my FS, it took 4 days to move 25GBs of data.
It's long term
On 10/22/2014 03:10 AM, Robert White wrote:
Each snapshot is effectively stapling down one version of your
entire metadata tree, right ?
On the best of my knowledge, I cannot confirm that.
I understood (please, be free to correct me if I am wrong) that each snapshot
create a copy of the
So I've been considering some NOCOW files (for VM disk images), but some
questions arose. IS there a 1COW (copy on write only once) flag or are
the following operations dangerous or undefined?
(1) The page https://btrfs.wiki.kernel.org/index.php/FAQ (section Can
copy-on-write be turned off
On Wed, Oct 22, 2014 at 12:41:10PM -0700, Robert White wrote:
So I've been considering some NOCOW files (for VM disk images), but
some questions arose. IS there a 1COW (copy on write only once)
flag or are the following operations dangerous or undefined?
(1) The page
On Wed, Oct 22, 2014 at 07:41:32AM +, Duncan wrote:
Tomasz Chmielewski posted on Wed, 22 Oct 2014 09:14:14 +0200 as excerpted:
Tho that is of course per subvolume. If you have multiple subvolumes
on the same filesystem, that can still end up being a thousand or two
snapshots per
So the documentation is clear that you can't mount a swap file through
BTRFS (unless you use a loop device).
Why isn't a NOCOW file that has been fully pre-allocated -- as with
fallocate(1) -- not suitable for swapping?
I found one reference to an unimplemented feature necessary for swap,
On Wed, Oct 22, 2014 at 01:08:48PM -0700, Robert White wrote:
So the documentation is clear that you can't mount a swap file
through BTRFS (unless you use a loop device).
Why isn't a NOCOW file that has been fully pre-allocated -- as with
fallocate(1) -- not suitable for swapping?
I found
On 10/22/2014 01:08 PM, Zygo Blaxell wrote:
I have datasets where I record 14000+ snapshots of filesystem directory
trees scraped from test machines and aggregated onto a single server
for deduplication...but I store each snapshot as a git commit, not as
a btrfs snapshot or even subvolume.
We
On 10/22/2014 01:25 PM, Hugo Mills wrote:
The new code is the swap-on-NFS infrastructure, which indirects
swapfile accesses through the filesystem code. The reason you have to
do that with NFS is because NFS doesn't expose a block device at all,
so you can't get a list of blocks on an
On Wed, Oct 22, 2014 at 01:39:58PM -0700, Robert White wrote:
On 10/22/2014 01:25 PM, Hugo Mills wrote:
The new code is the swap-on-NFS infrastructure, which indirects
swapfile accesses through the filesystem code. The reason you have to
do that with NFS is because NFS doesn't expose a
On 10/22/2014 01:42 PM, Hugo Mills wrote:
swap-on-NFS is still, I think, in a set of out of tree patches, and
it's not gone anywhere near btrfs yet. It's just that once it does
land in mainline, it would form the appropriate infrastructure to
develop swapfile capability for btrfs.
I just
Just hit this while running trinity.
WARNING: CPU: 3 PID: 9612 at fs/btrfs/extent-tree.c:3799
btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]()
Modules linked in: rfcomm hidp bnep af_key llc2 scsi_transport_iscsi nfnetlink
sctp libcrc32c can_raw can_bcm nfc caif_socket caif af_802154
On Wed, Oct 22, 2014 at 09:07:31PM -0400, Dave Jones wrote:
Just hit this while running trinity.
WARNING: CPU: 3 PID: 9612 at fs/btrfs/extent-tree.c:3799
btrfs_free_reserved_data_space+0x1d1/0x280 [btrfs]()
Modules linked in: rfcomm hidp bnep af_key llc2 scsi_transport_iscsi
Steps to reproduce:
# mkfs.btrfs -f /dev/sdb7
# mount /dev/sdb7 /mnt
# btrfs dev stats /dev/sdb7
output:
[/dev/sdb7].write_io_errs 0
[/dev/sdb7].read_io_errs0
[/dev/sdb7].flush_io_errs 0
[/dev/sdb7].corruption_errs 0
When btrfs allocate a chunk, it will try to alloc up to 1G for data and
256M for metadata, or 10% of all the writeable space if there is enough
space for the stripe on device.
However, when we run out of space, this allocation may cause unbalanced
chunk allocation.
For example, there are only 1G
Dave posted on Wed, 22 Oct 2014 08:49:46 -0400 as excerpted:
On Tue, Oct 21, 2014 at 10:08 PM, Duncan 1i5t5.dun...@cox.net wrote:
As for the mounted filesystem question, since all it does is flip a
switch so that new metadata writes use the skinny-metadata code path,
it shouldn't be a
Chris Murphy posted on Wed, 22 Oct 2014 12:15:25 -0400 as excerpted:
Granted I'm ignoring the fact there are 5000+ snapshots[.]
The short term, maybe even medium term, it's doctor, it hurts
when I do this! and the doctor says, well then don't do that!
LOL! Nicely said! =:^)
--
Duncan -
On Wed, Oct 22, 2014 at 01:37:15PM -0700, Robert White wrote:
On 10/22/2014 01:08 PM, Zygo Blaxell wrote:
I have datasets where I record 14000+ snapshots of filesystem directory
trees scraped from test machines and aggregated onto a single server
for deduplication...but I store each snapshot
Robert White posted on Wed, 22 Oct 2014 12:41:10 -0700 as excerpted:
So I've been considering some NOCOW files (for VM disk images), but some
questions arose. IS there a 1COW (copy on write only once) flag or are
the following operations dangerous or undefined?
(1) The page
On Oct 22, 2014, at 4:08 PM, Zygo Blaxell zblax...@furryterror.org wrote:
If you have one subvolume per user and 1000 user directories on a server,
it's only 5 snapshots per user (last hour, last day, last week, last
month, and last year).
Sure. So if Btrfs is meant to address
On 10/22/2014 09:30 PM, Chris Murphy wrote:
Sure. So if Btrfs is meant to address scalability, then perhaps at the moment
it's falling short. As it's easy to add large drives and get very large
multiple device volumes, the snapshotting needs to scale also.
I'd say per user, it's reasonable to
32 matches
Mail list logo
