GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-09-05) - page 1 of 10
 
___________________________________________________________________
WinBtrfs - A Windows driver for the next-generation Linux
filesystem Btrfs
95 points by doener
https://github.com/maharmstone/btrfs
___________________________________________________________________
 
sebazzz - 5 hours ago
Looks interesting. If this is possible, I wonder why a driver for a
much more common filesystem like ext hasn't picked of (e2fs driver
does not count, that is ext2 only).Why do you also check the
artifacts in?
 
  metafex - 5 hours ago
  There is ext2fsd (https://sourceforge.net/projects/ext2fsd).
  Worked like a charm last time I had to use it. Last version  is
  even from July.edit: Unsupported features: 1, journal: log-based
  operations, external journal 2, EA (extended attributes), ACL
  support
 
    seiferteric - 5 hours ago
    Ya I am using this and works with ext3/4 as well, but as you
    mentioned, there are some unsupported features. Unfortunately
    that means that it messes with some metadata or something and I
    have to run e2fsck when I reboot into linux. You can read about
    it here https://askubuntu.com/questions/849872/how-can-i
    -prevent-win...
 
    [deleted]
 
pjc50 - 3 hours ago
Nice work. I've starred this simply because examples of Windows
filesystem driver source are extremely rare. As are people familiar
with both Windows and Linux development, which have very differnt
styles and conventions.
 
sabujp - 4 hours ago
great, so when do we get xfs natively in windows?
 
  oneplane - 2 hours ago
  Probably never. We don't even have ext3 or ext4 support, only
  some bare ext2. And then there is the dozen or so other
  filesystems that would be handy to have. Microsoft doesn't care,
  they also don't have a business case for it, and they rather
  reinvent the wheel instead, using their own fs.The FOSS community
  doesn't really care that much either, mostly because Linux can
  deal with NTFS, and the other way around happens far less, so no
  real push has been made for it.
 
alfredxing - 2 hours ago
What's interesting to me is that there doesn't seem to be a modern
filesystem that works across all major platforms. btrfs has Linux
and this (unofficial) Windows driver; ZFS has Linux and OS X
support but nothing for Windows. NTFS is pretty much Windows and
Linux only for good write access, and APFS is macOS-only.I realize
that designing a filesystem and writing drivers for it are very
difficult tasks, but surely it would be extremely beneficial to
have at least 1 open source filesystem that has good support across
all platforms?
 
  pknopf - 42 minutes ago
  Fat has good support across all platforms.
 
  awalton - 1 hours ago
  > surely it would be extremely beneficial to have at least 1 open
  source filesystem that has good support across all platformsThe
  comedy of this is that there are actually plenty of FSes common
  to all three of these OSes, they're just not considered "modern";
  FAT32 is still the most commonly used FS for interop, even as it
  shows its age with poor support for very large files (2+GB) and
  file systems, but you also have ISO(9660) and (the best answer we
  currently have) UDF supported by all three OSes natively and
  openly without patents or other licensing restrictions. The
  latter two are not commonly used as read/write filesystems, but
  have zero inherent restrictions on being able to be used in such
  a way.However, the problem has been largely supplanted by having
  a fast and well-functioning network and people moving to "The
  Cloud" for, well, everything. It's hard to know how much of the
  Great Cloud Migration is caused by these kinds of intentionally
  engineered interoperability fails, especially the monumentally
  stupid exFAT patent... It's interesting to ponder given the
  people likely to complain the most about filesystems today are
  people who want to move large files (4+GB) between OSes without
  anguish, where the network is still just too slow to handle the
  task well.
 
    justabystander - 6 minutes ago
    > UDF supported by all three OSes natively and openlyWasn't
    there a major problem in that all the operating systems
    supported different versions of the UDF standard? And most of
    them treat it as an optical disk format, so I wouldn't be
    surprised if some of them acted like it was read-only.
 
  fooker - 1 hours ago
  exFat works reliably across all three.
 
    cosarara97 - 1 hours ago
    You can't fix exfat errors on linux (fsck just reports the
    errors).
 
    boondaburrah - 1 hours ago
    Sadly, exFat doesn't work reliably on Windows as I've had
    random software fail when data is stored on a drive formatted
    with exFat.Mostly that's the software's fault, mistakenly
    assuming anything "not NTFS" is FAT32 and insisting I need to
    "upgrade" my drives, even though I'm only using it as project
    storage.I honestly don't know why user mode software can tell
    what format the volume is in, and wouldn't just expect the OS
    to handle it or provide various feature flags like
    VOLUME_SUPPORT_LARGE_FILES or so.
 
      fooker - 1 hours ago
      'Random software' should not know anything about which file
      system your drive has.   If it does (..say.. some kind of
      whole disk backup utility), and you are using an unexpected
      file system that is not really a problem in exFat.
 
        Spivak - 4 minutes ago
        Just a simple counterexample, SQLite is not supported on
        NFS. Applications are not as insulated from the underlying
        storage as you suggest.
 
  marcoperaza - 2 hours ago
  I believe that part of the issue is that the file systems are
  tailored to the needs of the operating system they run on. Take
  file permissions. As the basic permissions model, Linux uses
  user/group/everyone, while Windows uses ACLs. Linux also supports
  ACLs but they don't work in the same way that Windows' does. NTFS
  is built to meet the needs of Windows, while Ext4 is built to
  meet the needs of Linux. You can use each on the other OS with
  the right drivers, but just as data drives with very roughly
  mapped permissions.
 
    alfredxing - 2 hours ago
    Hmm, that's a good point! However I don't think this would be a
    major hurdle: file permissions offer OS-level security only,
    not disk-level security/encryption, so it would still make
    sense for different OS drivers to implement only their specific
    permissions attributes.
 
joshstrange - 4 hours ago
I'm using BTRFS on my SSD and while it has some neat features the
need to rebalance periodically or you can "run out of space" while
using less than half the SSD drives me crazy.
 
  cmurf - 3 hours ago
  Kernel 4.8 and newer have a new ticketed enospc infrastructure
  that should avoid this, there's also earlier changes where empty
  block groups are deallocated automatically. If you're already
  using 4.8+ then try 4.12.6 or newer, which includes commit
  4a309747.Due to past long standing enospc challenges, more
  experienced users are in the (bad) habit of micro-managing Btrfs
  manually with filtered balance, e.g. -dusage=15 -musage=15.
  Really we kinda need to stop doing that to find and fix the
  remaining edge cases; or worst case upstream should deploy a
  systemd timer / cron job to do these partial balances maybe once
  a week.Anyway I don't balance at all on my drives and haven't run
  into enospc in quite a while. So chances are you're hitting an
  edge case, and there's a bug that needs to be tracked down if
  you're already using 4.12.6+.
 
    joshstrange - 3 hours ago
    When I get home I'll have to check. I'm using it via UnRAID so
    I don't have as much control over the version I run but they
    are pretty good about releasing updates, I'm just bad about
    applying them and restarting because taking down Plex is a sin
    punishable by death lol
 
      cmurf - 3 hours ago
      Looks like that same 4.12.6 fix is in 4.9.42.
 
_benj - 2 hours ago
This should have been done by Microsoft long ago, even before their
little "Microsoft <3 Linux" gimmick with bash.Still, a step in the
right direction, at least on my book. My shared drives are all
exFAT and that seems to work fine out of the box for Linux, Win and
macOS.
 
jsiepkes - 2 hours ago
Really cool! Does anyone know of the other way around; An open
source Windows next gen FS (ReFS) driver for Linux?
 
cmurf - 3 hours ago
Would this be easier, or harder if it were FUSE based?
 
  Xophmeister - 2 hours ago
  FUSE is a Unix thing. I believe there is a port/similar thing for
  Windows, but I guess it would suffer the same kinds of
  limitations; namely performance, because everything is translated
  through userspace. That said, isn't it true that Windows drivers
  are userspace-based, anyway?
 
    dom0 - 2 hours ago
    There are multiple projects providing user-space file systems
    for Windows, dokany and WinFSP for example.> That said, isn't
    it true that Windows drivers are userspace-based, anyway?No.
 
      Xophmeister - 2 hours ago
      Fair enough :)
 
    invokestatic - 2 hours ago
    All file system drivers must be kernel-mode on Windows.  While
    Windows does have usermode drivers (UMDF), it's significantly
    gimped.  Mostly just simple USB drivers or WDDM display
    drivers.There have been a few projects to try to bring FUSE-
    like functionality to Windows like Dokan but I believe these
    are still too immature.
 
      icebraining - 51 minutes ago
      WinFsp seems pretty good: https://github.com/billziss-
      gh/winfsp
 
newscracker - 5 hours ago
This seems like a good start, and it could help provide more choice
in cross-platform data storage and data exchange. Recently I looked
once again, as I usually do once every few years, at options for
exchanging data through external drives between Windows, macOS and
Linux (I prefer USB drives, which are faster than speeds I can
attain over the network). Shockingly, it seemed to me like NTFS was
the easier filesystem to go with (Linux has good support for it,
and macOS needs a third party driver for write support)!Back to
this project, I feel there is a strong need to have a set of GUI
tools (beyond Windows Shell Extensions) to take advantage of the
btrfs filesystem features (like creating snapshots, sending
snapshots to backup storage, etc.). I use btrfs on Linux, and the
lack of good, up-to-date GUI tools to use its feature set has been
a source of frustration (yes, I can use the command line, but then
that would restrict the usage only to me, leaving out the other
not-so-tech-savvy people around).
 
  teddyh - 5 hours ago
  > options for exchanging data through external drives between
  Windows, macOS and LinuxHow is the UDF support on macOS?  I ask
  since I relatively recently chose UDF as the Windows/Linux common
  HDD file system format, but I did not consider macOS.
 
    cmurf - 3 hours ago
    The trick for cross platform UDF is formatting the whole stick
    as UDF, without partitioning (no MBR, GPT, or APM). In that
    case, it works, I tested this just last week on Windows 10,
    Fedora 26, macOS 10.12.It's totally sane. It's "like" FAT32
    except you don't have the 2G filesize limitation. NTFS might
    also be sane, but out of the box macOS doesn't have write
    support.
 
  lucaspiller - 5 hours ago
  There's also ExFAT which is natively supported by Windows and
  MacOS.
 
    monocasa - 4 hours ago
    And was created pretty much because the last patents on FAT32
    finally expired.
 
      limeblack - 4 hours ago
      As a video editer the fuctionally of ExFat compared to Fat32
      isn't even close to what I need them for.  Fat32 can't store
      files larger then 4GB which is basically 99% percent of 4K
      videos that I deal with.
 
        monocasa - 34 minutes ago
        I would have preferred either a minimal update extending
        FAT32 to FAT64 (sort of like the extension from FAT12 to
        FAT32), or a better filesystem with journaling/etc.
 
    feelandcoffee - 3 hours ago
    ExFat it's great for USB flash drives and a easy way to get
    around this. But I had a few bad experiences with the lack of
    journaling working with a HDD.Maybe not a deal breaker for a
    lot, but for crucial data, my advice will be build a cheap NAS
    with Linux inside, and pass all data between OSs over network
 
  extra88 - 1 hours ago
  Right, macOS has had NTFS read support for quite a few years. I
  recently heard that the native driver can be enabled to provide
  write support as well. I just googled it and it requires editing
  /etc/fstab on a per-drive basis and has some
  downsides.http://www.techrepublic.com/article/pro-tip-enable-
  ntfs-writ...
 
    cpach - 1 hours ago
    There are also commercial products available, e.g. https://www
    .paragon-software.com/ufsdhome/ntfs-mac/
 
ehutch79 - 5 hours ago
I thought btrfs was being phased out in linux distros?
 
  jlgaddis - 5 hours ago
  Just RHEL.  Certainly not OpenSUSE.
 
    rantanplan - 4 hours ago
    Just RHEL. The biggest(or 2nd biggest) contributor to the Linux
    kernel.
 
      kuschku - 4 hours ago
      And smallest contributor to btrfs
 
  akerro - 5 hours ago
  It was nothing more than a political move.
 
  georgyo - 5 hours ago
  The smallest btrfs contributer, redhat, phased out support. They
  were the only ones to do so.
 
    agumonkey - 3 hours ago
    What has been the reaction from the rest of the "team" ?
    "doesnt matter" ?
 
      fleetfox - 2 hours ago
      SUSE uses btrfs as default and they posted this
      https://www.suse.com/communities/blog/butter-bei-die-fische/
      as response
 
    jo909 - 2 hours ago
    Just to clarify, redhat never offered full support for btrfs,
    it was only a technology preview that they did not continue. So
    it was never "supported" in their commercial support agreement
    and not intended for production usage.
 
  DCKing - 2 hours ago
  Ugh RHEL stopping commercial btrfs support in their long term
  support kernels [1] does not equate to btrfs "being phased out in
  linux distros". It's just Red Hat, and Red Hat was never a major
  btrfs promoter. It's also just commercial support, all Red Hat,
  Canonical and SUSE kernels will continue to be able to use it.I'm
  not a btrfs fan myself (quite the opposite) but the gross way in
  which this minor Red Hat move is being exaggerated as the end of
  btrfs makes me think something's up. People are willing to spread
  the FUD a little too easily. Fact is that btrfs is still one of
  the top two most advanced filesystems in the world, part of the
  kernel, and SUSE for one is all in on it.[1] They have legitimate
  reasons: it's a big chunk of code to maintain backports for and
  not at all popular in RHEL deployments.
 
    xelxebar - 2 hours ago
    Would you mind sharing your reasons for being a btrfs anti-
    fan?I decided to go with btrfs on my work and personal
    computers a couple years back and haven't really had to battle
    it.Just curious of your thoughts more than anything.
 
      DCKing - 2 hours ago
      I got bitten quite hard by some edge cases in the combination
      of btrfs, LUKS and snapper in desktop usage. It was both
      btrfs and the tooling around it as well as my ignorance. It's
      not a very interesting story.
 
  cookiecaper - 3 hours ago
  Ubuntu ships ZFS with their kernels. While this isn't an explicit
  thing, it strongly implies that Canonical doesn't have full
  confidence in btrfs.As others have stated, Red Hat explicitly
  pulled engineering resources off btrfs.ZFS just blows btrfs out
  of the water, there is really no comparison. As painful as it is
  to say, after all these years, btrfs still really feels like a
  rough draft of a modern filesystem.That's no insult to the people
  who've done amazing work on btrfs over the years, it's just
  calling a spade a spade. Something was just missing in its
  development; maybe it was vision, cohesion, whatever it was at an
  organizational level, something stopped btrfs from really coming
  together as a first-class enterprise-ready FS. We should
  recognize that and let it go, as Canonical and Red Hat have
  gradually been doing.
 
    Fnoord - 57 minutes ago
    Is it possible to run ZFS on Windows?
 
brian_herman - 1 hours ago
Why is it a reimplementation from scratch? Why not use the linux
kernel source?
 
  awalton - 1 hours ago
  Why not reimplement it and prove the filesystem can be
  reimplemented sanely, and furthermore now has multiple
  implementations to test the specification against?