vice (sshfs) ?
You could also go the totally cool option (albeit a bit creazy) and use
network block devices and have no downtime...
The overall process will take more time though.
--
Hubert Kario
QBS - Quality Business Software
ul. Ksawerów 30/85
02-656 Warszawa
POLAND
tel. +48 (22) 646-6
ntly, but I haven't
> received any reply. Could you review them for me? though I have tested
> them and everything works well.
>
> [PATCH 1/2] btrfs: restructure try_release_extent_buffer()
> [PATCH 2/2] btrfs: fix oops when leafsize is greator than nodesize
> [PATCH] b
functionality
> described in that article is more concerned with a bad transaction
> rather then something like a hardware failure where a block written
> more then 128 transactions ago is now corrupted and consiquently the
> entire partition is now unmountable( that is what I think i a
i need the ability to "move" the default subvolume into a new, empty
> subvolume. the empty subvolume then becomes the new default.
>
> the end result is moving the users installation into a dedicated
> subvolume, cleanly and efficiently, so the system can do other things
> with th
sing COW and referencing blocks in the original file (in
effect using only a little more space after splitting)
3. copy fragments to flash disks
the amount of I/O in the second case is limited only to metadata operations,
in the first case, all data must be duplicated
--
Hubert Kario
QBS - Quali
that the 'cp --reflink=always'?
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
System Zarządzania Jakością
zgodny z normą ISO 9001:2000
--
To unsubscribe from this list: send the line "unsubscribe li
ng of SSD)
>
> Considering that sparse files have been a reality for decades and that
> the implementation of operation with inside-file byte-grained extents
> is not more difficult than truncate, I wonder if we will see something
> of this kind in some advanced filesystem
On Monday 31 May 2010 19:59:46 Paul Millar wrote:
> Hi Hubert,
>
> On Thursday 27 May 2010 16:56:00 Hubert Kario wrote:
> > > Would [obtaining file checksum] be possible (without an awful lot
> > > of work)?
> >
> > [Calculating checksum in-memory] won&#
should be looking at ECC
RAM as subsequent checks can be affected by it to.
Second, you shouldn't tie application or network protocol to a CRC scheme used
by filesystem on server! Especially when there can be other CRC algorithms
used, not only CRC-32C.
If the checksum algorithm used by
Alpha), it's a bug it even tries to mount it on x86.
Regards,
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
System Zarządzania Jakością
zgodny z normą ISO 9001:2000
--
To unsubscribe from this list: send th
Inappropriate ioctl for device
>
> i'm not really familiar with C, or anything this low level, does this
> help you diagnose my problem?
Have you tried to run it on the device with the btrfs, not the mount point?
It looks like the ioctl was made too restrictive about its a
On Wednesday 17 March 2010 16:33:41 Leszek Ciesielski wrote:
> On Wed, Mar 17, 2010 at 4:25 PM, Hubert Kario wrote:
> > On Wednesday 17 March 2010 09:48:18 Heinz-Josef Claes wrote:
> >> Hi,
> >>
> >> just want to add one correction to your thoughts:
> &g
-line
data deduplication, but I think, that in-line dedup will see much less use.
>
> Naturally, you would not use this feature for all kind of use cases (eg.
> heavily used database), but I think there is enough need.
>
> my 2 cents,
> Heinz-Josef Claes
--
Hubert Kario
QBS
deduplication, there are already plans to do (probably) a userland daemon
traversing the FS and merging indentical extents -- giving you post-process
deduplication.
For a rather heavy used host (such as a VM host) you'd probably want to use
post-process dedup -- as the daemon can be easly s
to coordinate efforts and
solidify the interface.
--
Hubert Kario
QBS - Quality Business Software
ul. Ksawerów 30/85
02-656 Warszawa
POLAND
tel. +48 (22) 646-61-51, 646-74-24
fax +48 (22) 646-61-50
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
n non-tech language.
No, it's not this. When a SSD is fresh, the undeling write leveling has many
blocks to choose from, so it's blaizing fast. The same holds true when the
test uses small amount of data (relative to SSD size).
"very hard to benchmark" means just that -- the be
On Saturday 13 March 2010 18:02:10 Stephan von Krawczynski wrote:
> On Fri, 12 Mar 2010 17:00:08 +0100
> Hubert Kario wrote:
> > > Even on true
> > > spinning disks your assumption is wrong for relocated sectors.
> >
> > Which we don't have to worry a
On Friday 12 March 2010 10:15:28 Stephan von Krawczynski wrote:
> On Fri, 12 Mar 2010 02:07:40 +0100
>
> Hubert Kario wrote:
> > > [...]
> > > If the FS were to be smart and know about the 256kb requirement, it
> > > would do a read/modify/write cy
device do do rmw
cycles, only write cycle or erase cycle, provided there's free space and the
free space doesn't have considerably more write cycles than the already
allocated data.
>
> It's a great place for research and people are definitely looking at it.
>
> But with al
cking your head in the sand
> >> because you cannot be bothered to think.
> >
> > And your guess is that intel engineers had no glue when designing the XE
> > including its controller? You think they did not know what you and me
>
> know
>
> > and
> > t
s the SSD making sure all blocks are more or less equally
> written to avoid continuous load on the same blocks.
Isn't this all about wear leveling? TRIM has no meaning for magnetic media.
It's used to tell the drive which parts of medium contain only junk data and
can be used in
sig for the users to talk about double, triple
replication or [single|double]-parity.
It's a bit silly to talk about "Arrays of Disks" when we mean groups of
blocks.
--
Hubert Kario
QBS - Quality Business Software
ul. Ksawerów 30/85
02-656 Warszawa
POLAND
tel. +48 (22) 646-61-51,
On Wednesday 03 March 2010 00:22:31 jim owens wrote:
> Hubert Kario wrote:
> > On Tuesday 02 March 2010 03:29:05 Robert Collins wrote:
> >> As I say, I realise this is queued to get addressed anyway, but it seems
> >> like a realistic thing for people to do (use Backup
don't know
whatever it could be possible to optimise btrfs cow system for files that are
exactly the same.
>
> Cheers,
> Rob
>
--
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawerów 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
System Zarzą
101 - 124 of 124 matches
Mail list logo
