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 fi
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 whe
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 f
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 th
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® Parallel Studio Eval
Try the new s
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 200
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 documenta
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
> a
On Thu, Apr 8, 2010 at 12:39 AM, 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.
>
> However, from what I see, this is basically similar to what BackuPC does. The
> big problem I ha
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 perfor
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
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 be
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
mac
14 matches
Mail list logo