Date: Fri, 31 Jan 2003 19:51:24 +0100 From: phk@freebsd.org To: Steve Byan <stephen_byan@maxtor.com> Cc: freebsd-fs@freebsd.org, tech-kern@netbsd.org Subject: Re: DEV_B_SIZE Message-ID: <19187.1044039084@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 31 Jan 2003 13:41:35 EST." <A02737C6-354B-11D7-B26B-00306548867E@maxtor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <A02737C6-354B-11D7-B26B-00306548867E@maxtor.com>, Steve Byan writes : >> The only thing that exposes us to risk is we don't know the risk >> exists, so as long as the fact that a 4k physical sector size is >> used is not hidden from us, we can adapt. > >But would existing code be functionally broken (perhaps with respect to >failure recovery) if it were to not be modified to adapt to a different >physical block size? Not broken any worse than because of write-caching. >> Nope. > >Really? fsck can recover from losing 4K bytes surrounding the last >metadata block written? If the fragment size is 4k when the filsystem is created, and this would happen automatically, then there is no window for lossage. The thing we really need is working tagged-queing... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19187.1044039084>