Here's a quick patch to src/console/console.c
with implementation to -e command line switch to bconsole.
http://snap.co.ru/~mator/one-command-console.c.patch
On 25.05.2010 / 10:33:27 -0400, Morty Abzug wrote:
On Tue, May 25, 2010 at 05:13:36PM +0400, Anatoly Pugachev wrote:
On 04.05.2010 /
On Tuesday 04 May 2010 10:45:16 Craig Ringer wrote:
On 4/05/2010 11:45 AM, Morty Abzug wrote:
file dedup (rather than block dedup) could mostly be handled at the
catalog level with another level of indirection. I.e. instead of a
catalog entry containing file metadata and where the file
On 4/05/2010 11:45 AM, Morty Abzug wrote:
file dedup (rather than block dedup) could mostly be handled at the
catalog level with another level of indirection. I.e. instead of a
catalog entry containing file metadata and where the file lives on
media, it would contain file metadata and a
On Tue, May 04, 2010 at 04:45:16PM +0800, Craig Ringer wrote:
On 4/05/2010 11:45 AM, Morty Abzug wrote:
file dedup (rather than block dedup) could mostly be handled at the
catalog level with another level of indirection. I.e. instead of a
catalog entry containing file metadata and where the
On Thu, Apr 08, 2010 at 08:39:04AM +0200, Kern Sibbald wrote:
However, from what I see, this is basically similar to what BackuPC
does. The big problem I have with it is that it does not scale well
to thousands of machines.
file dedup (rather than block dedup) could mostly be handled at the
Hello,
I haven't seen the original messages, so I am not sure if I understand the
full concept here so my remarks may not be pertinent.
However, from what I see, this is basically similar to what BackuPC does. The
big problem I have with it is that it does not scale well to thousands of
Kern Sibbald wrote:
Hello,
I haven't seen the original messages, so I am not sure if I understand the
full concept here so my remarks may not be pertinent.
Personally I wasn't suggesting a format change - I'm pretty happy with
the fake-tape volumes for on-disk storage (though I wish
On 04/08/10 03:53, Craig Ringer wrote:
BTW, When I suggested that greater write concurrency would be desirable
and should be easier, Phil Stracchino raised some concerns about
concurrent writes to a file system increasing fragmentation and hurting
overall performance. Rather than just wave my
Phil Stracchino wrote:
On 04/08/10 03:53, Craig Ringer wrote:
BTW, When I suggested that greater write concurrency would be desirable
and should be easier, Phil Stracchino raised some concerns about
concurrent writes to a file system increasing fragmentation and hurting
overall performance.
On Thu, Apr 8, 2010 at 12:39 AM, Kern Sibbald k...@sibbald.com wrote:
Hello,
I haven't seen the original messages, so I am not sure if I understand the
full concept here so my remarks may not be pertinent.
However, from what I see, this is basically similar to what BackuPC does. The
big
On 04/08/10 09:13, Craig Ringer wrote:
Phil Stracchino wrote:
I'll be interested to see those results. Which filesystems are you testing?
I'm interested in ext3, ext4 and xfs. I should probably look at zfs too,
but don't have any hosts that it runs on usefully and don't really have
any
Craig Ringer wrote:
I'm interested in ext3, ext4 and xfs. I should probably look at zfs too,
but don't have any hosts that it runs on usefully and don't really have
any personal interest in it.
You may find the XFS mount directive, filestreams of benefit here.
There is not much documentation
On Fri, April 9, 2010 05:09, Richard Scobie wrote:
[snip]
You may find the XFS mount directive, filestreams of benefit here.
And using the 64-bit XFS will also better[1] than the standard 32-bit XFS.
Or the hybrid 32-bit XFS using 64-bit layout rules. (Damn, I only left
SGI at the end of 2008
Gary R. Schmidt wrote:
And using the 64-bit XFS will also better[1] than the standard 32-bit XFS.
That would be using the inode64 mount option.
Regards,
Richard
--
Download Intel#174; Parallel Studio Eval
Try the new
14 matches
Mail list logo
