Re: [Dng] OT - It may be only one file, but it does point to the bigger problem
On Mon, 23 Feb 2015 16:46:34 -0600 T.J. Duchene t.j.duch...@gmail.com wrote: My philosopher as a free software author is this: The buck stops with me. If my software screws up, it's my fault and my responsibility to fix, regardless of the actual root cause is in code I wrote or a tool I use. If I were having problems with two different compilers treating my code two different ways, I'd #ifdef the hell out of it to kludge it back to working order on both. But that's just me. I've seen a lot of free software authors say hey, it's not my fault, it's the __ library or tool. Doesn't help the user a heck of a lot. SteveT That's a fair point, in an overall sense, Steve. I'm afraid as a matter of practicality, I must disagree. Debugging on a compiler is a very specific skill-set. Asking someone who doesn't do that every day to fix what is probably a compiler bug is asking a lot - especially when you may have to venture into the realm of processor mnemonics and specific registers to fix the problem. In my opinion, that is especially relevant when dealing with ARM because there are so many makers of ARM processors with specific tweaks. T.J. Ahhh, now we're in my turf: Troubleshooting. If ARM restricts your choice of compilers, then I'll agree with you vis-a-vis ARM, sort of. For the wider application of my philosophy, it's amazing how little subject matter expertise (in this case tracing a compiler all the way down to instructions and registers) one needs in order to troubleshoot very effectively. Just as one example, in my classes I teach the power of having one system malfunctioning and one not malfunctioning. You can continue making each like the other until you can toggle the symptom with one statement. I call it exploit the differences, and it's very powerful. So, let's say that I can narrow it down to (just to pull an imaginary example out of the air) clang crashing on memset() while gcc doesn't. Obviously, I'd better be sure the locale is the same on both. The next step could be writing a simplest case that does nothing but a memset, and see if it still crashes on memset(). If so, then I could write my own memset, and see if that crashes, and investigate why. Eventually perhaps, on clang, I could ifdef in my own memset(). Or, if I have the skills, I could trace memset into assembler. Perhaps a single memset wouldn't reproduce the symptom. I can then keep reducing the program until I get the smallest program that can reproduce the symptom, and experiment with that. And of course, the most likely scenario will be that it's *my* bad code, not the compilers, but even if I can prove it's the compiler's, I can work around it while I wait for the compiler guys to fix their compiler now that I've reported the problem. When I find a situation of unexpected behavior with a library or tool, I usually just work around it and report it to the library devs. The last thing the user needs is me and the library devs pointing fingers at each other. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT - It may be only one file, but it does point to the bigger problem!
On Tue, Feb 24, 2015 at 12:57 AM, Noel Torres env...@rolamasao.org wrote: We have RAID tools like mdadm for RAID, and filesystems like ext4 or Reiserfs for file storage. Why would I want a tool combining both? You'd want one so you can, for isntance, avoid a RAID5 write hole. ZFS seems pretty cool, the only downside i see is perhaps more fragmentation that other systems. Cheers, Nuno ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT - It may be only one file, but it does point to the bigger problem!
On Mon, Feb 23, 2015 at 11:47:16AM +0100, Didier Kryn wrote: As far as I understand, COW means that the whole file is rewritten everytime you change a single byte in it (or is it only some extent?). That's a real mess when you are continuously appending to files hundreds of megabytes large, which is the job of a log server. No, only a single block. This is sometimes unwanted as it causes fragmentation -- your nice contiguous extents will split into small page/leaf-sized blocks all around, but NOCOW is still a terrible idea. It breaks pretty much all reasons one might want btrfs over an old-style filesystem (other than compression and checksums). NOCOW breaks the semantics behind reflinks and snapshots, which mean you can't use them for cloning stuff, backups, etc, anymore. Thus, every single program that uses NOCOW without an explicit request from the admin is broken and shouldn't be used anywhere near btrfs. If you happen to loose the log files, you don't loose precious data. If you have two clones, writing to one will overwrite the other. If you try to roll back to an old snapshot, whether for forensic or data recovery reasons, the log is lost. Nevertheless I would rather use a different filesystem for /var for example and keep btrfs for /usr and /home. Having all dpkg-managed files (ie, / except /home, /srv, perhaps /var/cache and friends if you micromanage) on a single btrfs subvolume is required for proper atomic snapshots. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT - It may be only one file, but it does point to the bigger problem!
On Sunday, 22 de February de 2015 18:28:06 Jim Murphy escribió: [...] If I have a btrfs mirror and I didn't mess with it by setting FS_NOCOW, shouldn't I be able to recover the file? I would sure hope so. He creates this better way of logging, then he seems to not even care if you can use it. Isn't btrfs the contrary to KISS? We have RAID tools like mdadm for RAID, and filesystems like ext4 or Reiserfs for file storage. Why would I want a tool combining both? er Envite -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? OpenPGP key: 1586 50C8 7DBF B050 DE62 EA12 70B4 00F3 EEC7 C372 Spiral galaxies always have at least TWO arms. signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT - It may be only one file, but it does point to the bigger problem
On Monday, February 23, 2015 04:46:34 PM you wrote: My philosopher as a free software author is this: The buck stops with me. If my software screws up, it's my fault and my responsibility to fix, regardless of the actual root cause is in code I wrote or a tool I use. If I were having problems with two different compilers treating my code two different ways, I'd #ifdef the hell out of it to kludge it back to working order on both. But that's just me. I've seen a lot of free software authors say hey, it's not my fault, it's the __ library or tool. Doesn't help the user a heck of a lot. SteveT That's a fair point, in an overall sense, Steve. I'm afraid as a matter of practicality, I must disagree. Debugging on a compiler is a very specific skill-set. Asking someone who doesn't do that every day to fix what is probably a compiler bug is asking a lot - especially when you may have to venture into the realm of processor mnemonics and specific registers to fix the problem. In my opinion, that is especially relevant when dealing with ARM because there are so many makers of ARM processors with specific tweaks. T.J. I realize I should have spoken more clearly and for that I apologize. I'll endeavor to be clearer in the future. What I was trying say is that, I agree that you should make every effort to make sure your code works, ultimately you are somewhat hostage to the compiler. The average programmer has no skills in that area, and they should simply not make a greater mess by altering their design to accommodate someone else's flaw. These chains of flaws go one for years. What is really scary is that eventually people's code *depends* upon the flaw, and that - to me at least - is unacceptable. As a matter of personal pride, I refuse to kludge up my code to fix bugs in other people's code. Readable code is un-kludged code. If possible, I will hunt down the bug and fix it. If that is not possible, I will either rewrite the code to not trigger the bug, or a patch will be placed in a separate file to check for processor type. Have a great day! T.J. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng