Slashdot Mirror

Repair work is _not_ "Click Here" or otherwise for n00bs.

If the USB isn't being read right, first check the hardware -- look at the output of `dmesg` under Ubuntu or other Linux. At the bottom there should be recent USB event entries.

Presuming the USB interface isn't fried (no entries), then check the master boot record (MBR) with `fdisk /dev/wherever`. All the USB keys I have seen emulate hard-disks and have the MBR. Quite possibly it has gotten messed up by a MS-Windows virus, improper disconnect or other. Without a correct MBR or superfloppy sig, no OS can interpret the data on the disk.

You can certainly reformat the filesystem once the MBR is fixed, but avoid totally replacing the MBR or otherwise repartitioning unless you know all about flash erase blocksizes and alignment. Ty T'so has a nice discussion for SSD here.

I'm not sure if you're aware of it, but the Transitive Grace Period Public License requires releasing of source code after 12 months. It's an interesting idea that I've seen around a few places.

You don't need to mount it as ext2, just make the filesystem with “mke2fs -t ext4 -O ^has_journal /dev/sdXX”. However I'm not fully convinced that is needed with a modern fast SSD that supports trim combined with an operating system that also supports trim.

Here are some measurements: http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/ though it's not perfect as they are measuring transferred megabytes which is not a good indicator of IO's.

(I think that) It's probably misaligned. LVM uses a 192k sector size for it's metadata. See Theodore Ts'o's post for more information.

It looks to me that this should *really* be fixed by WD with a firmware update

.

Solution: Instead of fdisk, call it as fdisk -H 224 -S 56 as per Theodore Tso's blog.

Wow, work for Redhat? Stockholder? :)

Other distros are closer to mainline and this is really all I'm saying. Redhat may claim their code is more appropriate for the enterprise - and maybe it is. But any guise of maturity is an illusion. They run 2.6.18 with almost 4000 patches consisting of almost 4 million lines, that they've been developing in parallel with mainline for almost 4 years. If their patches are pulled from mainline, or are similar, or different, or one day get merged, or not, the bottom line is this is a monumental effort, their kernel is different and diverging, and it is not more "mature" than mainline - it's just coming from a different team with different processes, priorities, and people.

By comaprison Ubuntu 9.10 has divergence too, from 2.6.31. Their patch - in a single file - is about 308k lines - or less than 10% of Redhat's effort in terms of volume. Their 8.04 LTS release (which is more like RHEL in conservative approach) is based on 2.6.24, and that patch runs ~551k lines since Spring 2008, as it nears the end of its support life in a couple of months.

If you want to argue semantics, it is pretty fun, I won't stop you. Just don't fool yourself that you're doing anything more, or that you really sound more convincing giving a definition than, say...

"As Linus Torvalds has pointed out, in the Open Source world, there always are forks; whenever someone creates a patch and submits it for inclusion, a fork is temporarily created." -tytso

Does Redhat get a lot of its patches merged, ultimately? Why yes they do. So it's an amicable fork not so different from the old AC kernels - in fact, that has its roots in them.

"And certainly "code forks" in the form of the Alan Cox, David Jones, Andrea VM trees, et. al, have certainly not hurt the Linux kernel development community; in fact, they are an important and invaluable part of the Linux development process." --ibid

Look, you are better off arguing that Redhat is a fork and it is more relevant than mainline, since more people use it. Or maybe you are actually arguing that, I'm not sure.

But you can read what I wrote - I don't make any claims about reliability. I only tell my story and raise the question. It's about mindshare, and often when companies try to go it alone on this stuff, they get in over their heads. In a way, every old unix variant tells this story...

This is a familiar discussion, although the assertion about not being able to cite your own work is bogus. I suspect that everybody in academia expects a new online publication model to emerge, but this is certainly taking a long time to converge.

The issue of so-called "intellectual property" is another recurring discussion, even outside the rabid FOSS ranks. See, for example (to cite myself as well as others): http://thunk.org/tytso/blog/2008/11/29/an-ethical-question-involving-ebooks.

The absolutists here may want to consider a couple of complications. First, what about the very frequent case of multiple authorship? Without a third party such as a journal to whom to reassign copyright, the authors would constantly have to squabble between themselves about who - jointly, severally or individually - would retain copyright and in what proportions. Second, most corporate or educational institutions require their staff to sign over ownership of intellectual work products as a basis for employment in the first place.

There is no simple Platonic ideal of "property", let alone something called "intellectual property". The laws that exist (at least in origin) were primarily intended to defend the rights of the body politic, not of the individual "creator". Further, the notion of a truly individual creator is a fantasy. Newton saw further because he stood upon the shoulders of giants. (Or should I have quoted that 382 years after his death?)

After reading the comments on my earlier post, Delayed allocation and the zero-length file problem as well as some of the comments on the Slashdot story as well as the Ubuntu bug, itâ(TM)s become very clear to me that there are a lot of myths and misplaced concerns about fsync() and how best to use it. I thought it would be appropriate to correct as many of these misunderstandings about fsync() in one comprehensive blog posting.

http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

FYI, Ts'o is the ext4 maintainer.

After the Ext4 dataloss discussion, and the "Don't fear the fsync()" posts, I don't want to hear about Ext4, fsync(), or data loss again.

This "guy" is Theodore Ts'o and he's one of the most brilliant and respected Linux kernel hackers. http://en.wikipedia.org/wiki/Theodore_Ts'o http://thunk.org/tytso/

It also depends on what type of filesystem you use. A journaling filesystem like ext3 can wear down a disk a lot faster than a non-journaling filesystem.

Not true. If you have a decent SSD that doesn't have Write Amplification problems (such as the X25-M), the extra overhead of journalling really isn't that bad. I wrote about this quite recently on my blog.