You are still going to have to have at least 29 levels to accomodate 1
billion
objects, though they won't all be full (sorry I missed the must be full or
empty
bit). So it looks like we'll have to actually search what 13 rows right?
So
still more rows than a b-tree, and again you are
I'd like to see how they do that. The fact is you are still going to get
random
seeks since you have to binary search the blocks in an entire row since
there is
no way you can read a several thousand block row into memory to search it,
so
once your rows get pretty big you are doing just as
Hi,
One of my disks, partitioned into a single btrfs partition, is showing
media errors. The problem is that these errors lead to kernel panic from
btrfs - that make the filesystem unusable until reboot - and therefore
it is very hard for me to do a full backup of the data prior to changing
The plan that occurs to me is to make a snapshot of the system in the
state that I want to always boot. Then, I would rewrite the init
script in the initrd to (a) delete any old tmp copy of the snapshot;
(b) copy the static snapshot to a tmp copy; (c) mount the tmp copy.
That's a little
On Mon, Jan 09, 2012 at 04:21:31PM +0100, Niels de Carpentier wrote:
The plan that occurs to me is to make a snapshot of the system in the
state that I want to always boot. Then, I would rewrite the init
script in the initrd to (a) delete any old tmp copy of the snapshot;
(b) copy
On Sun, Jan 1, 2012 at 12:12 AM, Niels de Carpentier
ni...@decarpentier.com wrote:
... and depending on which SSD you use, it shouldn't matter. Really.
Last time I tried with sandforce SSD + btrfs + -o discard, forcing
trim actually made things slower. Sandforce (and probably other modern
... and depending on which SSD you use, it shouldn't matter. Really.
Last time I tried with sandforce SSD + btrfs + -o discard, forcing
trim actually made things slower. Sandforce (and probably other modern
SSD) controllers can work just fine even without explicit trim fs
support.
What
You mean like zfs send -i? If yes, why not just use zfs? There's
zfsonlinux project, with easy-to-install ppa for ubuntu. Or you could
compile it manually.
Thank you for your suggestion. As I know, there is not everything ported
yet, and one of the missing important features I plan to use
For btrfs bugs are still fixed on a daily basis, and some reports of
people with corrupted and unrecoverable filesystems.
I don't know that there's been any actual unrecoverable filesystems
recently; unmountable is by far the more common issue, and given that
most sane people aren't putting
It seems I trust the web pages too much - in http://zfsonlinux.org/ is
written that it does not ;O)) otherwise I would be using it already.
From the website:
Please keep in mind the current 0.5.2 stable release does not yet support
a mountable filesystem. This functionality is currently
How is this advantageous over dmcrypt-LUKS?
For example mixing encrypted and not encrypted subvolumes in one pool.
And not having to separately cryptsetup luksOpen all disks consisting
filesystem.
There are advantages of FDE like dm-crypt and selective encryption like
in ZFS.
I think
11 matches
Mail list logo
