Ubuntu 19.10 Indeed Working On "Experimental ZFS Option" In Ubiquity Installer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Niarbeht
    replied
    Originally posted by k1e0x View Post
    FreeNAS isn't exactly Vanilla FreeBSD.. It's based on FreeBSD but with changes from TrueOS/HEAD.

    It's close but the ZFS features don't match 1:1.

    At least not yet, Unification day (ZoL integration) is coming, it's already in Ports and HEAD.
    Insert Firefly reference here.

    Leave a comment:


  • k1e0x
    replied
    FreeNAS isn't exactly Vanilla FreeBSD.. It's based on FreeBSD but with changes from TrueOS/HEAD.

    It's close but the ZFS features don't match 1:1.

    At least not yet, Unification day (ZoL integration) is coming, it's already in Ports and HEAD.
    Last edited by k1e0x; 08 July 2019, 03:22 PM.

    Leave a comment:


  • Niarbeht
    replied
    Originally posted by starshipeleven View Post
    There is a misunderstanding here, I was just quoting the figures I know from the modern ZFS experience I have (mostly on FreeNAS storage appliances, which is FreeBSD) and I genuinely asked if this change down to 70 bytes was a ZoL thing or if I really was a dinosaur or if it was the FreeNAS community that kept repeating the same old wife's tales.

    Also, for the "Lunix" thing it was just a joke. I use OpenSUSE Tumbleweed on my PC and NAS, with btrfs, (and this isn't hard to check), I'm not a *BSD zealot.
    Alrighty, yeah, miscommunication. Sorry :/

    I have no idea if it's made its way through everywhere, but I'm pretty sure there are a lot of old wive's tales floating around regarding ZFS. I'd suspect it's more likely that a strong optimization like that, that's been around for several years, has managed to work its way through to everything. If I weren't at work, I'd probably crawl through the ZFS sources and compare what L2ARC in-memory structures are like on the different implementations. If you're feeling up to the task, it might make for a good thing to post to the FreeNAS forums or whatever. Might also consider asking on the ZFS subreddit so you can get an expert to chime in so you've got something to point to in the future.

    I remember this from looking into why L2ARC is 70 bytes per record versus dedup still being large. I have a suspicion that dedup can be shrunk similarly, though maybe not as much, but I dropped looking into that like six months ago I think.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Niarbeht View Post
    If FreeBSD didn't pull in an optimization that strong, maybe you should quit with the "Lunix" bullshit and step down off your high horse. That's a memory use optimization that reduces usage by a little over five times. That's significant. That's a massive disadvantage for FreeBSD. And since that optimization has been around since at least ZoL 0.6.5.11, that's a long time to let something that good go to waste.
    There is a misunderstanding here, I was just quoting the figures I know from the modern ZFS experience I have (mostly on FreeNAS storage appliances, which is FreeBSD) and I genuinely asked if this change down to 70 bytes was a ZoL thing or if I really was a dinosaur or if it was the FreeNAS community that kept repeating the same old wife's tales.

    Also, for the "Lunix" thing it was just a joke. I use OpenSUSE Tumbleweed on my PC and NAS, with btrfs, (and this isn't hard to check), I'm not a *BSD zealot.

    Leave a comment:


  • Niarbeht
    replied
    Originally posted by starshipeleven View Post
    Also on FreeBSD's ZFS? (not that it matters much now, since they are migrating to the ZoL)
    If FreeBSD didn't pull in an optimization that strong, maybe you should quit with the "Lunix" bullshit and step down off your high horse. That's a memory use optimization that reduces usage by a little over five times. That's significant. That's a massive disadvantage for FreeBSD. And since that optimization has been around since at least ZoL 0.6.5.11, that's a long time to let something that good go to waste.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Niarbeht View Post

    L2ARC header size has been 70 bytes for a few years now. Get with the times.
    Also on FreeBSD's ZFS? (not that it matters much now, since they are migrating to the ZoL)

    Leave a comment:


  • Niarbeht
    replied
    Originally posted by starshipeleven View Post
    Ah crap I forgot that ZFS users on Lunix (tm) use a 128k block size.

    L2ARC eats 400bytes per block so the total consumption depends from the block size.

    On FreeNAS the default is 16k or 8k, for each 100GB of SSD L2ARC you need like 2.5GB or 5GB respectively. That's kind of significant. With 128k block size it's negligible.
    L2ARC header size has been 70 bytes for a few years now. Get with the times.

    Leave a comment:


  • Dr.N0
    replied
    If anyone is interested, I just found out you can support the maintainer of ZFS on Mac & Windows, Jörgen Lundman, on Patreon: https://www.patreon.com/lundman.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by nivedita View Post
    For a client device 100gb sounds like way overkill.
    I said "serious arrays" above when I talked of "caches" (and meaning L2ARC).

    Leave a comment:


  • nivedita
    replied
    Originally posted by starshipeleven View Post
    Ah crap I forgot that ZFS users on Lunix (tm) use a 128k block size.

    L2ARC eats 400bytes per block so the total consumption depends from the block size.

    On FreeNAS the default is 16k or 8k, for each 100GB of SSD L2ARC you need like 2.5GB or 5GB respectively. That's kind of significant. With 128k block size it's negligible.
    For a client device 100gb sounds like way overkill. Remember l2arc is not persistent so it needs to repopulate on each boot. People with servers sometimes run initialization code to bring stuff into the arc for this reason. You might be better off running lvmcache underneath zfs instead.

    Leave a comment:

Working...
X