The following patchset enables cramfs to mount images that were created on a machine whose endianness differs from the mounting machine's one. Tested on an i386 box. A discussion about this feature can be found here: http://marc.info/?l=linux-fsdevel&m=119438573309330&w=2 Andi -

This patch updates the readme file according to the new mount option "swapendian". Signed-off-by: Andi Drebes <andi@programmierforen.de> --- fs/cramfs/README | 21 +++++++++------------ 1 files changed, 9 insertions(+), 12 deletions(-) diff --git a/fs/cramfs/README b/fs/cramfs/README index 445d1c2..acbbdc4 100644 --- a/fs/cramfs/README +++ b/fs/cramfs/README @@ -1,3 +1,12 @@ +Mount options +------------- + +Currently, there is only one mount option available for cramfs: + +swape...

Codingstyle: extra space after "if", keep brace on the same line. Same goes for most of this patch. Unlikely not likely to be a good idea. It clutters up the code for a minimal gain on host-endian filesystems (and I doubt you can measure that even in micro-benchmarks) and forcibly mispredicts every branch for cross-endian filesystems. The name "endian" could be replaces with something more descriptive. You could remove most of this by removing the mount option and simply You're using Xe...

This is a valid objection. The problem is that the endianness for cramfs has never been standardized. Now there are filesystem images in both little and big endian out there. I encountered this problem first when I tried to mount my router's initrd. Yes, I know, I could have converted the image into little endian. I just find that it is more consistent to support both kinds Actually, in my eyes, it would be better to create a new version of cramfs that standardizes the endianness and the block size. B...

I decided to compress the metadata when I designed Squashfs, a read-only filesystem which was inspired by Cramfs. Squashfs stores the data at the front of the filesystem and puts the metadata at the end, so the data is always at a fixed point. Doing that and a couple of other things allows the metadata to be built up and compressed in one-pass while the filesystem is being created. The metadata is split into an inode table and a directory table and compressed separately because it compresses...

So? Normally the initrd goes with the kernel anyway. Linus -

We can do proper typechecking with sparse even for dual-endian filesystems, see ufs and sysvfs for example. And yes, for a new filesystems I'd always chose one endianes and stick to it, but becase I certain someone forgot that when creating cramfs we're stuck now :) -

I'm somewhat confused by the complexity. Currently we can already have a lot of dirty pages from FUSE (up to the per BDI dirty limit - so basically up to the total dirty limit). How is having them dirty from mmap'ed writes different? -

Ah, ok, your initial story missed this part (not being intimately familiar with FUSE made all that somewhat obscure). The next point then, I'd expect your fuse_page_mkwrite() to push writeout of your 32-odd mmap pages instead of poll. -

The unused part is gone, I've not yet found a way to re-distribute this fairly. [ It's one of my open-problems, I can do a min_ratio per bdi, but not yet a max_ratio ] -

The idea here is separate "conscious" from "unconscious" flushes. Conscious flushes are those due to a fsync() or close(). Unconscious ones are flushes that occur as a side effect of some other operation or due to memory pressure. Currently, when an error occurs during an unconscious flush (ENOSPC or EIO), we toss out the page and don't preserve that error to report to the user when a conscious flush occurs. If after the unconscious flush, there are no more dirty pages for the inode, the conscious ...

I did some digging. The code was merged between 28.4.1999 and 11.5.1999, as it first appears in 2.2.8 and 2.3.0: /* * The page cache can done in larger chunks than * one page, because it allows for more efficient * throughput (it can then be mapped into user * space in smaller chunks for same flexibility). * * Or rather, it _will_ be done in larger chunks. */ #define PAGE_CACHE_SHIFT PAGE_SHIFT #define PAGE_CACHE_SIZE PAGE_SIZE #define PAGE_CACHE_MASK PAGE_MASK...

I think that what Nick was trying to say is that PAGE_CACHE_SIZE should always be used properly as the size of the memory struct Page covers (while PAGE_SIZE is the hardware page size and the constraint is that PAGE_CACHE_SIZE == (PAGE_SIZE << k) for some k >= 0). If everybody does that then "None of the filesystems should really care at all". That said, it doesn't seem like the current usage in fs/ and drivers/ -

That's because you're thinking about all these difficulties outside the about the least problematic here. -

Linus made comments about it on the git list which restarted it. Beagle's writing to the xattrs makes git think the file has been changed. It was really a fs question not git so I forwarded it to this group. Git wouldn't have a problem if there was a way for Beagle to avoid using the xattrs. Discussion of the general problem have been going on for a long time and has caused the creation of dnofity and inotify. But the problem is still not completely solved since there are these windows where file...

That doesn't answer my question. I didn't ask about 'pagecache pages' per se. Are you saying then that a page struct always represents an area of PAGE_SIZE to, say, the page allocator and PAGE_CACHE_SIZE to a filesystem's address operations? How about I state it this way: Please define what the coverage of a (non-compound) struct page is, and how this relates to PAGE_SIZE and Compound pages are irrelevant to my question. A compound page is actually a regulated by a series of page structs, e...