Trying to design low level hard disk manipulation program
|
From: Terje Mathisen on 25 Sep 2006 14:30 Jonathan Thornburg -- remove -animal to reply wrote: > In article <pdblu3-9hh.ln1(a)osl016lin.hda.hydro.com> Terje Mathisen then > commented: >>> Case-blind case-preserving is the only variant which is acceptable from the >>> point of view of ergonomics, IMNSHO. >> There I agree. This obeys the principle of least surprise, but as noted >> above, it does still have drawbacks. > > Are you saying that your idea of the POLS is that because the two > pathnames are in the same directory, and have filenames which (let us > say, in the current locale) compare as equal according to strcoll(3), > then the 2nd file should overwrite the 1st? Ick. As I said, it does have drawbacks. Re. your particular example: BTDT. :-( The ntpd source code CVS repository had at one point in time two different files in the same (unix) directory, that varied only in the case of one letter. This was a really ugly bug when trying to compile ntpd for Windows. :-( I still contend that a world which stops you from creating multiple files that vary only in case would be good, but as long as we have to coexist with file systems which doesn't, the only real solution is as you say, i.e. to have the base filesystem be case-ignorant. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Bill Todd on 25 Sep 2006 15:24 Terje Mathisen wrote: .... > It is _very_ obvious that even home users could/will need some form of > sector-level data redundancy to store their digital home videos, RAW > photos etc. I don't think it's obvious at all. If people don't care enough to protect against whole-disk failure by keeping backup copies, then there's no reason to stand on our heads to try to protect against sector-level failures. And if they *do* have backup copies, then the rare sector-level failure (very rare indeed if background scrubbing is employed) can be fixed from the backup data, as long as the file system is reasonably intelligent about replicating all (or at least critical) *metadata* in separated locations on the single disk to keep the overall structure robust. > > So, what can be done at the single-disk level? Aside from the metadata replication that I just mentioned above, nothing reasonable. If people want highly-available (as contrasted with backup-secured) access to every sector of their data, then they should mirror it on separate disks, period. - bill
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 25 Sep 2006 16:02 Tarjei T. Jensen <tarjei(a)online.no> wrote: > "Eric P." wrote: > > - [*] For disk file system at least, I think the time for compressed > > files has passed and are a waste of development time these days. > > Sorry content is balooning. We need everything in order to keep cost down. File formats are usually compressed already, and you need to know the kind of content to get the best compression. -- Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 25 Sep 2006 16:28 Terje Mathisen <terje.mathisen(a)hda.hydro.com> wrote: > Andrew Reilly wrote: > > On Mon, 25 Sep 2006 12:52:48 +0200, Terje Mathisen wrote: > > > >> For every N MB of contiguous disk space, use an extra MB to store ECC > >> info for the current block. The block size needs to be large enough that > >> a local soft spot which straddles two sectors cannot overwhelm the ECC > >> coding. > > > > Isn't that just the same as having the drive manufacturer use longer > > reed-solomon (forward error correcting) codes? Errors at that level are > > No, because you need _huge_ lengths to avoid the problem where an areas > of the disk is going bad. This really interferes with random access > benchmark numbers. :-( Whether you do it in the file system or in the drive firmware, benchmark numbers will suck equally, don't you think? -- Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 25 Sep 2006 16:28
Jan Vorbr?ggen <jvorbrueggen(a)not-mediasec.de> wrote: > > Case-blind file systems are a pox, if you've ever had to share code across > > filesystems, and your coleagues insist on saving headers in files with one > > case, but some different case appears in the source of the include > > statement... > > Say what? That is just the situation a case-blind system is designed to > handle gracefully! That was Andrew Reilly you quoted and I suspect that *his* filesystem is casesensitive, so *he* gets the problem. He could just go with the flow, of course. Anyway, preparing diskimages with filesystems of the required casesensitivity is an easy solution for those big balls of code that want one flavor. -- Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark |