On Tuesday 12 February 2008, Jan Engelhardt wrote: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 from doing something complex. IO is already aligned on sectors, sometimes we'll have a perfect erasure block alignment and sometimes not. When the location of the super is my biggest bottleneck, I'll be a very happy boy. -chris - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Ingo Molnar | [git pull] x86 arch updates for v2.6.25 |
| Anton Salikhmetov | [PATCH -v8 2/4] Update ctime and mtime for memory-mapped files |
git: | |
| Patrick McHardy | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 16/37] dccp: API to query the current TX/RX CCID |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
