-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/08/13 07:07, Josef Bacik wrote:
Not sure what strict allocate = yes does,
I've worked on SMB servers before and can answer that. Historically the
way Windows apps (right back into the 16 bit days) have made sure there is
space for a file
The main reason I started using strict allocate = yes on samba was out of
desperation/exasperation with BTRFS.
BTRFS stalls from time to time causing SAMBA and/or MSSQL to give up on
the dump of a database.
From what I have noticed, if for example you dump a 50GB database to samba
without strict
Mark Ridley posted on Fri, 23 Aug 2013 09:20:04 +0100 as excerpted:
I don't want to try nodatacow (which would probably fix the issue), but
you lose compression on the whole filesystem, autodefrag doesn't fix it
either.
I don't do servantware (in the context of my sig) and thus don't do samba
The speed improvement for dumping large databases through samba with
strict allocate = yes to BTRFS was amazing. It reduced a 1 hour dump down
to 20 minutes.
On 23/08/2013 09:01, Roger Binns rog...@rogerbinns.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/08/13 07:07, Josef
That would be fine, but nodatacow (according to the btrfs wiki) stops
compression, so I might as well get the speed benefits of 'strict allocate
= yes' which also disables compression.
If you want to use BTRFS to store backups then compression has be turned
on.
Database files like MSSQL usually
Hi,
The speed improvement for dumping large databases through samba with
strict allocate = yes to BTRFS was amazing. It reduced a 1 hour dump down
to 20 minutes.
What you want btrfs to do is to allocate a file of fixed-size on disk
in advance, without knowing how large the file will be after
On Thu, Aug 22, 2013 at 08:29:26PM +0200, Kai Krakow wrote:
Josef Bacik jba...@fusionio.com schrieb:
Not sure what strict allocate = yes does, but I assume it probably does
fallocate() in which case yeah we aren't going to compress, we'll just
write
into the preallocated space. We
