Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Compatibility with input plug-ins (Score 2) 400

supports a lot of formats

The only reason I've used Winamp in the past few years is that most of the players for music formats related to classic game consoles have been released as input plug-ins for Winamp. Does XMPlay support NSF (NES), GBS (Game Boy and Game Boy Color), SPC (Super NES), SGC (ColecoVision and Sega), GYM/VGM (Sega logged), PSF (PS1), USF (PS2), GSF (Game Boy Advance), and 2SF (Nintendo DS)? On the XMPlay page, I see "Game Music Emu input plugin", which covers the NSF, GBS, SPC, SGC, GYM, and VGM, but not PSF and friends. What worries me more is that the page also states a policy of making the input plug-in SDK available only to approved developers: "The input plugin SDK is currently available only on request. If you would like to create an XMPlay input plugin, please get in touch."

Comment Block-level RLE (Score 1) 135

Because that would require the flash to do deduplication and know that the blocks were full of FF and so could be copy-on-write (and, in your scheme, block-level compression)

Block-level run-length encoding is exactly what I had in mind. This way more logical sectors can be packed into one 64-128K erase page. A sector that has been compressed into "0x00, then 4095 more of the last byte" is as good as TRIMmed. It needs to be done anyway for file tails.

Comment Re:Poor man's TRIM (Score 1) 135

Perhaps you missed my implication: Instead of having a concept of empty sectors to begin with, just treat sectors with long runs of a constant value as highly compressible. You need to do that anyway for the last sector of a file, which contains on average half a sector of zeroes.

Comment Re:Secure deletion (Score 1) 135

for every bit a lossless compression algorithm shaves off one file, it must add to some other file

Pigeonhole principle. I'm aware of that.

Thus some files are actually made bigger than their size implies.

By about one byte, a marker that the sector is uncompressed. In a real file system, this overhead of one byte per sector is made up for by real files that contain real redundancy, such as the last sector of a file (or the only sector of a small file). On average, the last sector of a file will contain a run of half a sector's worth of $00 bytes. This and other cases where sectors can be compressed allow more logical sectors to fit into a single erase page.

Comment Secure deletion (Score 0) 135

Why go to the trouble of implementing a command implicitly when you can implement it explicitly and avoid unintended side effects?

Because the explicit command causes unintended side effects in drives manufactured prior to the command's introduction.

Not to mention operating systems would still need to change the way they handle the disk to support the 0xFF method

Any file system supporting "secure" deletion should be filling deleted files' sectors in the background anyway.

Comment The drive would decompress it (Score 1) 135

A sector full of only 0xFF might mean "I don't need this anymore" as well as "this file have a sector worth of 0xFF stored there".

Either way, when you read that sector back, the drive would decompress it to a string of 0xFF. This is true whether it's an "empty sector" or a row of white pixels in a BMP file.

Using trim, the FS/OS/whatever's on the line can tell the drive "ok, this part I don't need anymore, go play with it" in a non-ambiguous way.

What happens when the kernel attempts to read back a sector that hasn't been written since it was last TRIMmed?

Comment Some drives choke on TRIM (Score 1) 135

To make it work, the disk would have to look at every written block and see if it's "the empty block".

A lot of flash controllers already use compression of some sort to reduce write amplification. So a controller could just store which sectors compress to the smallest sizes. That wouldn't be much more effort than storing which sectors are TRIMmed, and it'd ensure a well-defined response when the kernel attempts to read a TRIMmed sector.

TRIM is faster and easier.

Unless, as Immerman pointed out, a particular drive chokes on it. Sending TRIM to a device that doesn't correctly support TRIM produces "undefined behavior", and even some drives that claim to support TRIM don't in fact. No drive chokes on constant fill.

Comment Poor man's TRIM (Score 1) 135

A filesystem just notes which blocks are erased, it doesn't actually erase them. [...] With TRIM, the OS can tell the disk which blocks are no longer needed, so that the disk can treat them like empty blocks

Why couldn't an operating system just write a big block of 0xFF bytes to an unused sector, which the SSD's controller would compress into an efficient representation of a low-information-content sector, instead of needing a dedicated command?

Comment Re:Can someone dumb-down the comment... (Score 5, Informative) 135

Solid-state drives (SSDs) are an alternative to hard disk drives using flash memory instead of spinning platters. This greatly improves read speeds but doesn't do quite as much for write speeds. One reason is that each sector on a solid-state drive can only be erased a finite number of times before it starts failing. For this reason, the microcontroller in an SSD perform wear leveling to spread writes across more physical sectors. TRIM is a feature that an operating system can use to notify a drive that a range of sectors has become unused, which helps wear leveling run more efficiently. A cron job is a program that runs periodically in the background, and Canonical (the publisher of Ubuntu, a distribution of the GNU/Linux operating system) wants to add a cron job that scans attached drives for unused sectors and sends TRIM commands for these sectors. It's possible for an operating system kernel to send a TRIM command for multiple ranges of sectors, but the current version of Linux doesn't know this and instead sends one range at a time. This slows down deleting files because the kernel has to notify the drive of each sector range as the file is deleted. To work around this missing feature of Linux, the cron job will TRIM when a drive isn't busy doing something else.

Slashdot Top Deals

I am more bored than you could ever possibly be. Go back to work.