The useless braces should be removed now. The "ifdef mania" should be cut by about a quarter by the following patch (following up on the patch idea posted late last week): http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=90c81e0b... -- Thanks, Steve -

On Sun, 10 Feb 2008 00:24:28 +0900 This seems rather arbitrary. Why choose this stage in the page reclaimation process rather than some other stage? If this feature is useful then I'd expect that some applications would want notification at different times, or at different levels of VM distress. So this semi-randomly-chosen notification point just won't be strong enough in real-world use. Does this change work correctly and appropriately for processes which are running in a cgroup memory con...

From: Chris Mason <chris.mason@oracle.com> Any page size larger than 4K will not work with btrfs. All of the extent stuff assumes that PAGE_SIZE <= sectorsize. I confirmed this by forcing mkfs.btrfs to use an 8K sectorsize on sparc64 and I was finally able to successfully mount a partition. With 4K there are zero's in the root tree node header, because it's extent's location on disk is at a sub-PAGE_SIZE multiple and the extent code doesn't handle that. You really need to start val...

The CRC32C implementation in the btrfs progs is different from the one in the kernel, so obviously nothing can possibly work on big-endian. This is getting less and less fun by the minute, I simply wanted to test btrfs on Niagara :-/ Here is a patch to fix that: --- vanilla/btrfs-progs-0.12/crc32c.c 2008-02-06 08:37:45.000000000 -0800 +++ btrfs-progs-0.12/crc32c.c 2008-02-12 01:19:33.000000000 -0800 @@ -91,13 +91,11 @@ static const u32 crc32c_table[256] = { * crc using table. */ -u3...

From: David Miller <davem@davemloft.net> Actually it seems this is only a problem with mkfs.btrfs, it clears out the first 64 4K chunks of the disk for whatever reason. The following patch cures the disk label spamming problem for me: --- vanilla/btrfs-progs-0.12/mkfs.c 2008-02-06 08:37:45.000000000 -0800 +++ btrfs-progs-0.12/mkfs.c 2008-02-12 00:07:43.000000000 -0800 @@ -210,7 +210,8 @@ int main(int ac, char **av) exit(1); } memset(buf, 0, sectorsize); - for(i = 0; i < 64; i...

From: Chris Mason <chris.mason@oracle.com> Sure. -

From: Jan Engelhardt <jengelh@computergmbh.de> So that existing superblocks on the partition won't be interpreted as correct by other filesystems. It's No, we won't do stupid things like that and make an entire cylinder of our disks unusable. See my other reply. -

Ok you do have a point there. The GPT users win of course, since it uses LBA, not cyls, so the number of lost bytes is generally below a cyl. On the other hand, the H and S of CHS could be lowered and S increased, e.g. divide H by 2, divide S by 2, multiply S by 4. This gives a finer Well it was designed for a different system initially with a different style of booting. -

From: Chris Mason <chris.mason@oracle.com> The Sun disk label sits in the first 512 bytes and the boot loader block sits in the second 512 bytes. I think leaving even more space is a good idea for several reasons. -

From: Jan Engelhardt <jengelh@computergmbh.de> You cannot specify partitions on LBA boundaries on sparc, the Sun disk label specifies the partition start points in cylinders. -

From: Chris Mason <chris.mason@oracle.com> Starting at 0 is a bad idea because otherwise you'll waste significant chunks of your disk on Sparc because of reasons I've outlined in other replies. What XFS does is really unfortunate, let's learn from it's mistake. -

From: Jan Engelhardt <jengelh@computergmbh.de> All of your beliefs are unfortunately without the understanding of restrictions that exist in several partition layouts such as the Sun disk label one. You have to start the superblock somewhere other than zero or else you lose a huge chunk of your disk, and furthermore a zero based partition is what all of the Sun disk label creating programs make by default. "I make a default disk label, I put btrfs or XFS on there, my disk label is gone...

Will all the users in the world who think about super block location when they partition their disks please raise their hands? The location of the super block needs to be very simple in order for mount and friends to find and detect it. It needs a simple algorithm to try multiple locations in case a given copy of the super is corrupt. Design in this case is a bunch of compromises around other users of the hardware, ease of programming, and the benefits in performance or usability IO is ...

Explaining it won't make it pretty, but at least I can tell you what the code does. This is all part of the btrfs code that supports tree block sizes larger than a page. The extent_buffer code (extent_io.c) provides a read/write api into an extent_buffer based on offsets from the start of the multi-page buffer. That's where the relative unsigned long comes from. The part where I cast it to pointers is me trying to maintain type checking throughout the code. The pointers themselves are u...

Good question. It's an eyesore to be sure. The duplication exists for the sake of retries combined with the separation of requests from commands. Please bear with me, if you're curious: commands can be launched without requests (at probe time, for instance, or when sense is requested). So, they need an s/g table. But then, the lifetime of a request is greater than than of a command, in case of a retry especially. Therefore a request needs the s/g table too. So, one way to kill this duplication...