This patch converts the existing pointer extensions from a switch statement
to an array of printf_operations.
The result is a very small pointer(), which only tests for null, tries
to expand typed pointers, and eventually falls back to numeric printing.
The previous version still had a print
The reiserfs string formatting code bounces back and forth between its
own internal formatting rules and those provided by vsnprintf. It's worked
alright, but depends on undefined behavior - behavior that changed in a recent
gcc release IIRC.
This patch eliminates the reiserfs-internal strin
This patch adds the ability to add arbitrary types to vsprintf rather
than adding every type to pointer().
Future users include reiserfs and btrfs, where it's much more
convenient to print messages with common data structures with a simple
printk rather than a series of them. It makes the cod
This patch converts the existing pointer extensions from a switch statement
to an array of printf_operations.
The result is a very small pointer(), which only tests for null, tries
to expand typed pointers, and eventually falls back to numeric printing.
Signed-off-by: Jeff Mahoney
---
lib/v
BTW, this is what I had in mind:
This patch adds the ability to add arbitrary types to vsprintf rather than
adding every type to pointer().
Future users include reiserfs and btrfs, where it's much more conventient
to print messages with common data structures with a simple printk rather
than
lee,
A couple of thoughts about your .26 lockup:
- I assume you are on the same hardware with 27.
- Are you using a module or builtin btrfs (I build it in).
- It looks like you are using vmware... when I'm doing kernel
stuff I want to be on the iron, not trusting virtual machine code.
(peo
I have updated my backport patch to apply cleanly to the experimental
btrfs branch as well as fix a couple of mistakes I had. I am still
having lockup issues on 2.6.26. My best guess right now is that there is
some sort of race condition going on. I'm trying to track it down but
I'm not having any
On Fri, 2009-02-20 at 11:01 -0500, Josef Bacik wrote:
> On Fri, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote:
> > hi all,
> > I would like to know what are the ssd specific optimisations in btrfs .
> > I read from the archives that
> >
> > "mount -o ssd option, which clusters fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Mason wrote:
> On Thu, 2009-02-19 at 19:39 -0500, Jeff Mahoney wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Shen Feng wrote:
>>> output objectid in btrfs_disk_key with human readable strings.
>>> Other updates are included for
On Fri, Feb 20, 2009 at 04:56:55PM +0530, srimugunthan dhandapani wrote:
> hi all,
> I would like to know what are the ssd specific optimisations in btrfs .
> I read from the archives that
>
> "mount -o ssd option, which clusters file data writes together regardless of
> the directory the files be
On Thu, 2009-02-19 at 19:39 -0500, Jeff Mahoney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Shen Feng wrote:
> > output objectid in btrfs_disk_key with human readable strings.
> > Other updates are included for more readable output.
>
> This gets messy fast. I'd like to see some
hi all,
I would like to know what are the ssd specific optimisations in btrfs .
I read from the archives that
"mount -o ssd option, which clusters file data writes together regardless of
the directory the files belong to. There are a number of other performance
tweaks for SSD, aimed at clustering
12 matches
Mail list logo