Picking the right filesystem across Win, Mac, and Linux

Posted on 16. Mar, 2010 by Bernie Thompson in Windows

Tuxera, a company that provides both open source and commercial filesystem drivers, announced the millionth download of NTFS for Mac today — that’s a large number, with many or most downloads being the free NTFS-3G solution.

We use NTFS-3G on Mac OS 10.4 here, in combination with the Plugable USB 2.0 SATA All-in-one Storage Dock and large TB+ SATA drives. Along with built-in NTFS support on Windows XP and up, and all recent Linux distros, this lets us easily swap a single USB cable between Windows, Mac, and Linux and have all three be able to read and write the drive(s).

Overall, this is a good solution for developers who have to span multiple platforms, for people who use boot camp to switch between Mac and Windows, or for increasingly common multi-platform offices that are using external storage docks for backup.

And it’s nice having a both an open source and a (better performing) commercially supported option.

It used to be that the venerable FAT32 filesystem was best way to format a drive to make sure you could easily read and write it from Windows, Mac, and Linux. But FAT32 has some limits that are especially problematic for today’s large drives 1 TB and up:

  • Hard limit of 4GB on any individual file (think home movies of 30 mins or more)
  • FAT32 needs large cluster size for large disks – which means wasted disk space in the case of many small files
  • Partition size limits that can get as small as 32GB, and certainly hit at 2TB

There are various ways to read and write filesystems native to one OS on another. But there are also lots of pitfalls. All things considered, NTFS is the best compromise today.

For more background:

Update on DisplayLink Linux support (udlfb in 2.6.34)

Posted on 14. Mar, 2010 by Bernie Thompson in udlfb

A 10-part udlfb patch series with several enhancements were recently accepted into the Linux kernel staging tree of 2.6.34. Greg’s maintainer patch series passing them on starts here.

This catches the official kernel staging tree with everything on git.plugable.com up to Feb, 2010.

Background

udlfb provides Linux framebuffer (fbdev) support plus a private “damage” notification ioctl used by the Roberto DeIoris’ “displaylink” X server. Udlfb automatically detects and supports all current DisplayLink USB graphics chips – 120,160,115,125,165,195. It supports 16bpp, with modes up to the maximum supported by the DisplayLink chips. Plugging any DisplayLink device into a Linux PC with this support should result in a “green screen” which means udlfb has loaded, set the monitor default mode, and drawn to the device successfully.

What udlfb does *not* do on its own is make configuring X easy – X sits on udlfb, but getting X running still involves editing configuration files like xorg.conf in different ways depending on what you’re trying to do, what distro version you have, and what primary GPU you have.

Features in Linux kernel 2.6.34 so far

  • Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears). Video playback, flash games, etc. are all improved
  • Asynchronous urb dispatch and no mutexes held for extended periods during render
  • Slightly lower CPU consumption, fewer non-localized memory accesses, slightly higher average compression
  • Better handling of switching from X to fbcon VTs and back
  • Driver unloads more cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
  • More standard EDID parsing and mode handling, using fbdev’s built in mode libraries (but creates a new dependency on them being enabled in kernel)
  • Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics* – but will move to debugfs)
  • EDID reported through sysfs (read /sys/class/graphics/graphics/fbX/edid)
  • Can compile as module with or without defio or sys_ dependencies
  • Lots of cleanup – tested on 64-bit, closer to endian clean, checkpatch.pl clean
  • Support for standard fbdev clients (via defio) – unfortunately buggy yet (see todos)

Depending on timing, some additional todo items might make it, we’ll see.

Versioning

At one point, we wanted udlfb to have its own project cycles and release versioning to help clarify things here while udlfb evolved in the early days. Got pushback on doing this from the kernel maintainers. So versioning of udlfb is purely by kernel version – “this bug is in udlfb in kernel 2.6.34rc1″ or whatever. There’ll also be a newer changes that haven’t been submitted to the kernel (e.g. at http://git.plugable.com/). And it’s probably best to just version that per commit/checkin. “This bug shows up in commit 234b4e22…”. This is nice in a way – just check the stuff in somewhere let the world know what you’re doing – the only “release process” you need to coordinate with is getting the patches into the kernel itself. Or feel free also to send patches here, we’ll try to help them through the process.

Todo

  • Add code to read pixel resolution limits from the device’s USB descriptors, and adhere to them. Avoids blank screen when monitors caps exceeds that of the adapter
  • Add pseudo-32bpp mode to help the case of using Xinerama to extend desktop across PCIe/USB adapters. Not planning true 24/32-bpp mode yet because of complexity and perf tradeoffs
  • Disable defio by default, unfortunately, because of several bugs without obvious solutions
    • rendering problems with pages (lines) that no longer get updated – writes to those are no longer triggering deferred processing
    • When running 2 USB adapters, dirty pages for one instance seem to affect the other, and vice versa (udlfb has no common state, so appears to be in defio or mmu handling)
    • cases where we hit a kernel oops in the deferred io handler when it tries to touch the pages it’s been asked to handle.
  • Move perf metrics from sysfs to debugfs and add ABI doc for what remains, per GregKH
  • Fix two ignored return values that Greg’s build environment caught
  • Get a safe method from DisplayLink to detect future chips that might not be compatible with current ones, and bail out of probe

There’s lot of other stuff that could be done – and any patches are very welcome. One big open question is whether fbdev has legs, or whether this effort should be converted over to KMS/DRM/DRI.

Upgraded Plugable Universal Docking Station

Posted on 06. Mar, 2010 by Bernie Thompson in Windows

The Plugable Universal Docking Station is getting some minor but nice upgrades to the latest chips for each function. All new units shipped from March 1, 2010 forward have these new features:

  • Upgraded the DisplayLink DL-160 to the newer DL-165
    • Previous maximum resolution was 1680×1050, now 1920×1080
  • Moved from two 4-port NEC USB hubs internally to a single FE 2.1 7 port USB hub
    • When using as a terminal, previously could daisy-chain 2 docks, now up to 4. All devices attached to the dock show on the same hub
  • Upgraded ASIX AX88772 ethernet chip to newer AX88772A
    • Auto-MDX support (automatically detects straight or cross-over cabling)

We’ve also shrunk the paper package size for less waste, and a have smaller connector for the (otherwise same) AC adapter.

The size and look of the docking station itself hasn’t changed, and all the same adapters, cables, and other hardware are included.

To the laptop docking station user on Windows or Mac, the changes won’t be immediately obvious, as the same drivers support both versions of hardware.

On Linux, both old and new chips have the same in-kernel support. In the terminal case, the USB configuration is now simpler (all devices are off the same USB hub), and that means a change in the udev rules for devices plugged into usb ports (keyboard and mouse are one hub less deep). Look for a future post on that.

So, with the new version, here’s the Windows Update experience you’ll see — without using any driver disks first, just plugging into a fresh Windows 7 machine with its own network connection up, letting it find and download drivers automatically.


Win7 first connect experience. Mouse and composite keyboard also attached

If you need to distinguish the versions from the outside (e.g. so you can make sure to give a newer one to someone who wants 1920×1080 resolution), the model number on the bottom of the older units all start with 0920J1.

Enjoy the upgrades on the new UD-160-A docking stations, and as always make use of our public problem reporting and support at http://getsatisfaction.com/plugable any time.

Page 4 of 10« First...2345610...Last »