| From | Subject | Date |
|---|---|---|
| Matthew Dillon | Re: HAMMER filesystem update - design document
I've never looked at the Reiser code though the comments I get from
friends who use it are on the order of 'extremely reliable but not
the fastest filesystem in the world'.
I don't expect HAMMER to be slow. A B-Tree typically uses a fairly
small radix in the 8-64 range (HAMMER uses 8 for now). A standard
indirect block methodology typically uses a much larger radix, such
as 512, but is only able to organize information in a very restricted,
linear way.
The...
| Oct 13, 8:59 pm 2007 |
| Matthew Dillon | Re: HAMMER filesystem update - design document
Theoretically a transaction id can be stored along with the quota state
and the quota state can be updated on the fly when a cluster gets
recovered. I wasn't planning on implementing quotas in HAMMER for 2.0
but it's definitely possible to do it without requiring a rescan.
-Matt
Matthew Dillon
<dillon@backplane.com>
| Oct 13, 7:36 pm 2007 |
| Thomas Zander | Re: HAMMER filesystem update - design document
Certainly I didn't mean to say that quota support for Hammer in 2.0
was the most important thing on earth. But as it is such a
feature-rich and modern filesystem approach, users will eventually
appreciate quota support at some stage of development.
I can't wait to test Hammer on my Pentium Pro box with 48M of RAM :-)
Riggs
| Oct 13, 10:51 pm 2007 |
| Matthew Dillon | Re: pmap of amd64
I don't think we can use swapgs. The problem with swapgs is that it's
a swap, not a load, which means it can only be used at the syscall
interface and can't be used at the interrupt or exception interface.
-Matt
Matthew Dillon
<dillon@backplane.com>
| Oct 13, 7:24 pm 2007 |
| Joerg Sonnenberger | Re: pmap of amd64
You don't have to play such games on AMD64 -- the swapgs instruction is
normally used by traps and system calls to load a well-defined address
base for that. Note that gs is expected to be used for, but that is a
minor detail.
Joerg
| Oct 13, 8:54 am 2007 |
| Thomas Zander | Re: HAMMER filesystem update - design document
Hi,
I hope this question has not been implicitly answered before, but how
does Hammer handle quotas? Filesystems like XFS and ZFS maintain quota
information internally so that a quotacheck after a system crash does
not take ages. It seems to me that Hammer could manage quotas as a
part of its cluster allocation strategy. Is this the case?
TIA,
RIggs
| Oct 13, 1:24 pm 2007 |
| previous day | today | next day |
|---|---|---|
| October 12, 2007 | October 13, 2007 | October 14, 2007 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Andi Kleen | Re: [PATCH] x86: Construct 32 bit boot time page tables in native format. |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | Re: Possible regression in HTB |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
git: | |
