<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>You may want to take a look at an article on IBM developerWorks. Talks about new filesystem features in the 3.3 and 3.4 Linux kernels, among other things:</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>http://www.ibm.com/developerworks/linux/library/l-33linuxkernel/index.html?cmp=dw&cpb=dw&ct=dwcon&cr=devx&ccy=zz</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style:
normal;"><span><br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">From:</span></b> Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us><br> <b><span style="font-weight: bold;">To:</span></b> conspire@linuxmafia.com <br> <b><span style="font-weight: bold;">Sent:</span></b> Thursday, August 9, 2012 10:05 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> [conspire] The practice of making ext4 a default needs to die an excruciating and gruesome death<br> </font> </div> <br>
Many here remember that for years I sang the praises of IBM's JFS. I<br>stopped doing that after it pissed me off one too many times. With JFS,<br>even the slightest unclean unmount means the file system will absolutely<br>refuse to be mounted ever again until you fsck it. If that file system<br>is connected by means of a flaky USB cable, that means one might need to<br>repeat hassle every couple of minutes. That's pretty frustrating, and so<br>is having to do that to the root file system after any unclean shutdown.<br>Every so often, that fsck would also automagically delete a random file<br>or two. Additionally, legacy GRUB could not read it beyond a certain<br>version, so one needed a /boot partition.<br><br>So, after enough of that, I looked into the state of btrfs and decided<br>not to take the plunge, especially after reading that existing ext4 file<br>systems could be converted in place to btrfs at any time by recreating<br>the metadata within the
free space and not touching the data itself. I<br>decided to tar up my entire hard disk onto an external (still formatted<br>with JFS, I might add) and mkfs.ext4 my JFS root, untarring things right<br>back to how they were. I replaced my old /boot with an image of<br>SystemRescueCD. This all succeeded just fine. I no longer had to deal<br>with mount not working, and fsck would even run itself without my<br>invoking it, just from my mounting an uncleanly unmounted file system.<br>Yey! (Not.) Said fsck would constantly notify me that it was clearing a<br>bunch of "orphaned inodes" i.e. it was wantonly deleting my files. :(<br><br>Some time earlier, I had noticed that after I had upgraded from Lucid to<br>Maverick, I began to experience random hardware freeze-ups. At this<br>point, I am hoping it might be because my laptop battery needs to be<br>replaced, and I hope they stop after I replace it. If they do not, I<br>will reapply the Arctic Silver 5 to the
CPU in hopes THAT will fix it.<br>If that still won't do it, I will return to the assumption that it is a<br>software-caused issue.<br><br>I use Tomboy Notes for a lot of handy things and I consider its<br>functionality essential, but I have no love for the piece of software<br>itself and the abhorrent Mono bloat it represents. I continue to use it,<br>having not bothered to investigate saner replacements.<br><br>One day, I was updating a simple financial ledger I was keeping in part<br>of one of the notes, and one of the aforementioned freeze-ups happened<br>as I was typing. Horrifyingly, the hard disk access light was lit and<br>not even flickering anymore. After the panic slightly subsided enough<br>for me to force reboot, I opened Tomboy Notes again, and that note was<br>no longer in the list. I dug into the directory where the notes are kept<br>(~/.local/share/tomboy) and found the note files themselves. They are<br>stored as XML files with UTF-8
header bytes. There was no file<br>corresponding to the missing note. Nothing else seemed to be gone. I<br>rebooted into SystemRescueCD and franticly ran several passes of<br>PhotoRec with various permutations of options. All it could turn up that<br>was of any use was a several-months-old version of that Tomboy note,<br>with too much newer data simply lost. I decided to grep the entire file<br>system itself for certain data I knew I had only in that note. Again,<br>all that could be found was that outdated version of the note.<br>SystemRescueCD kept running out of memory doing these things, so I<br>stupidly enabled the swap partition. Major facepalm when I then realized<br>that having failed to find the data anywhere else, I should grep THAT. I<br>turned off swap and did so. What seemed like a lifetime of panic came to<br>an end when one of the matches in swap turned out to be the missing<br>note, but in plain text and not XML for some reason. It was
not the most<br>current version either, but it was recent enough that I could<br>reconstruct the remaining missing data just from memory. Whew!<br><br>In the past, Rick had explained on this mailing list several reasons why<br>WUBI is bad. While attending SCaLE9x in 2011, I made a WUBI install of<br>Maverick Meerkat onto a certain person's Dell laptop that came with<br>Vista. With WUBI, a file is created in Windows's NTFS to be mounted on a<br>loopback device as the root file system in Ubuntu. A swap file is then<br>made in that root file system for virtual memory. Eek! This means that<br>the for the kernel swapper to page out, it needs to access the file by<br>going through the file system it's on, in turn by going through the<br>loopback device to the file where THAT lives, in turned by going through<br>the file system THAT lives on, which is NTFS, which is accessed by means<br>of the ntfs-3g _user space_ driver via FUSE. This of course means
that<br>an unclean unmount of said NTFS is a potential monkey wrench in the<br>works. The battery in that Dell completely failed less than a year after<br>that laptop was purchased brand-new from Best Buy. Dell insisted that<br>their one-year warranty did not extend to the battery. The DC jack on<br>that laptop is VERY loose. Inevitably, one time when the plug came out<br>as the computer was running, Ubuntu would not boot up again when power<br>was reapplied. Being the nearest technical person, I took a look. The<br>unclean unmount of the NTFS forced a CHKDSK, which found something wrong<br>with the inode for the file holding the loopback file system. As a<br>corrective measure, without human intervention, it simply deleted that<br>file. The reason Ubuntu was no longer booting was that it was no longer<br>present on the computer. I did some searching for some NTFS undelete<br>utilities, and I don't remember what I found, but I undeleted the<br>loopback
file, and Ubuntu lived again.<br><br>OK, now you've read the background information.<br><br>Some time ago, I got a call from Adrien saying he knew someone who was<br>having recurrent unspecified problems with Ubuntu after having migrated<br>from Windows. I spoke to this person, and he described a pattern of<br>having his systems compromised in a consistent way, and how this pattern<br>continued unabated after migrating away from Windows. I took a look at a<br>tower and a laptop. The tower had certain obvious issues stemming from<br>compounded user errors, but nothing blindingly obvious as an attack<br>vector. The laptop was peculiarly not starting X, which seemed to simply<br>die inexplicably when lightdm was supposed to start. After poking around<br>on the laptop console, I found that maybe half the dependencies of the<br>ubuntu-desktop metapackage were not considered by dpkg to be installed.<br>So, I did "apt-get install ubuntu-desktop" and after it
was done, a<br>reboot brought the system to life, with all its old settings. It seemed<br>to work just fine at that point. I engaged in some application installs<br>on the tower, withing the user account. Then I let things be. I come<br>back after a while, and the tower seems to be missing much of what I put<br>there, and the laptop no longer has working audio. Looking at the<br>laptop, I find that huge swaths of /lib/modules is simply gone,<br>including all sound drivers. Puzzled, I did a "sudo dpkg -i" of the<br>current kernel, which was still in /var/cache/apt/archives, and sound<br>worked again. Firefox also seemed to not be installed on the tower. It<br>was "rc" in "dpkg -l" and a "sudo apt-get install ubuntu-desktop" put it<br>back. The Windows installation I did under VirtualBox seemed to be gone<br>altogether from the user's home directory. I did "locate -i virtualbox"<br>and it showed that it was still there. I did similar queries with
other<br>things that were obviously missing, also showing still there, along with<br>contents of hidden dotfile directories that "ls -a" showed no trace of.<br>I know that Ubuntu updates the mlocate.db at 8am sharp every day if it<br>can. I asked whether the computer was on at 8am on that day. He said it<br>was, but he shut it down later in the morning. The modification<br>timestamp confirmed this. So, something had deleted large swaths of the<br>file systems of both the tower and the laptop within the preceding short<br>amount of time, when no one whatsoever had any physical access to either<br>machine until I was there, and the laptop also had no network<br>connection, with rfkill constantly in force, and Ethernet not plugged<br>in. He stated that this was an example of what keeps happening, and that<br>it used to happen under Windows as well, when it ran on bare metal. Of<br>course, given the background information above, I figured I should
ask:<br>"When you shut down the computer, exactly how do you usually do it?" You<br>can take a wild guess what his answer was…<br><br>This also leads me to believe, without having actually looked into it,<br>that certain files disappearing may cause dpkg to consider a package to<br>be in the "removed" state. Based on what I have heretofore known of<br>dpkg's inner workings, I would have assumed otherwise, but this<br>situation says to me that maybe dpkg actually does work that way.<br><br>In summary, ext4 is Not Ready for Prime Time. Any ideas what to replace<br>it with, folks?<br><br><br><br>_______________________________________________<br>conspire mailing list<br><a ymailto="mailto:conspire@linuxmafia.com" href="mailto:conspire@linuxmafia.com">conspire@linuxmafia.com</a><br><a href="http://linuxmafia.com/mailman/listinfo/conspire" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br><br><br> </div> </div> </div></body></html>