toasters

toasters@lists.teaparty.net

1 participants
13518 discussions

Re:
by Basil 18 Aug '21

18 Aug '21

Not from a position of experience, but if I had to hazard a guess, I think that deduplication would eventually cause all the blocks to be recognized and squished. On Wed, Aug 18, 2021 at 12:49 PM Scott Eno via Toasters < toasters(a)teaparty.net> wrote: > > > > ---------- Forwarded message ---------- > From: Scott Eno <cse(a)hey.com> > To: Toasters <toasters(a)teaparty.net> > Cc: > Bcc: > Date: Wed, 18 Aug 2021 12:46:10 -0400 > Subject: move files without snapshot growth? > Hi, > > Anyone on this list have a favorite way of moving files from one folder to > another folder on the same CIFS volume without causing snapshot growth? > > I gotta move 10TB+ of data from one folder structure to another folder > structure on the same CIFS vol. We keep snapshots for a year so I really > don't want to hang on to 10TB+ of snapshot data for a year. > > Can XCP do this somehow? Powershell? > > Sorry if this ends up wrapped in a no subject email. I don't know what > causing that. > > > > ---------- Forwarded message ---------- > From: Scott Eno via Toasters <toasters(a)teaparty.net> > To: Toasters <toasters(a)teaparty.net> > Cc: > Bcc: > Date: Wed, 18 Aug 2021 17:46:13 +0100 > Subject: > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > https://www.teaparty.net/mailman/listinfo/toasters

2 1

move files without snapshot growth?
by Scott Eno 18 Aug '21

18 Aug '21

Hi, Anyone on this list have a favorite way of moving files from one folder to another folder on the same CIFS volume without causing snapshot growth? I gotta move 10TB+ of data from one folder structure to another folder structure on the same CIFS vol. We keep snapshots for a year so I really don't want to hang on to 10TB+ of snapshot data for a year. Can XCP do this somehow? Powershell? Sorry if this ends up wrapped in a no subject email. I don't know what causing that.

1 0

Re: pNFS
by Michael Bergman 17 Aug '21

17 Aug '21

On 2021-08-17 14:26, Justin Parisi wrote: > NFSv4.1 performance is nearly identical to v3 in ONTAP for sequential > reads/writes. The performance issues mostly come from high metadata > workloads. If you do want to use v4.1, move to ONTAP 9.9.1 and the latest > Linux kernels you can. Yes. And therein lies the problem. Anything which has many files (high inode density), many open() and close() operations and lots of deletes of [small] files will suffer significantly (higher processing util in WAFL and extra latency) from using v4.1 The current performance penalties in v4.1 w.r.t. ONTAP compared to v3, are not easy to fix. Maybe something can be done inside ONTAP to mitigate but it's never going to "go away" easily to become on par overall with v3 performance any day soon. Metadata ops (esp GETATTRv3) is very very optimised in ONTAP in v3, for example I agree 100%: use 9.1.1 (latest stable Px whatever it is) and make sure that you have the latest Linux [kernel] version(s) you possibly can. It will help. (One of the very latest is highly preferable.) If you want to get proper enterprise level support, then use the latest RHEL 8.x, keep it well patched all the time, and you'll at least lower the risk if having issues. If you have a specific application system(s), e.g. one which really depends on v4.1 ACLs (I have yet to hear about such an animal that isn't esoteric) or some other feature v3 doesn't have (there aren't many IMO) then you can probably "contain", and hence control that environment much better including the involved NFS clients. If not... caveat emptor. /M -- Michael Bergman Sr Systems Analyst / Storage Architect michael.bergman(a)ericsson.com BNEW Service Area Networks, Lab Ops Phone +46 10 7152945 Global Network & Tech, Architecture SMS/MMS +46 70 5480835 Ericsson Torshamnsg 36, 16480 Sthlm, Sweden -- This communication is confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

1 0

Re: pNFS
by Michael Bergman 17 Aug '21

17 Aug '21

On 2021-08-17 14:23, Justin Parisi wrote: > Referrals probably have the same issue. Will need to test when I get back > into the office. Unless you seek to eliminate/avoid, all CI (Cluster Interconnect) traffic at all cost, I don't really see that that fact matters too much [at mount time]. (Good point about FlexGroups though... I don't have a good solid solution for those scenarios) We have since long (years) strived to avoid CI traffic as much as we can, but we're not as diligent anymore. Note: we do *not* use that DNS function ONTAP has in it which is intended to help spreading all the traffic (mount from clients) to various LIFs (based on the "load" on the nblades). Again, this takes place at mount time, once a mounts sits on a LIF it stays there... That DNS function (it is based on an algorithm using various "weights") suffers from serious drawbacks in some situations and we can't take that risk in our environment. Anyone who has seen and experienced a "mount storm" will know what I mean. How important locality is (minimal CI traffic) for you I guess can depend a bit on what model/power of CI switch you have. If there's enough bandwidth for the workload streams going across it, it only induces a little extra latency -- that may matter for some workloads, but I'd argue that for most it won't. Once you're on CI switch with 100 GbE, my take is that most people don't have to bother that much about it. With 100 GbE the latency is lower as well /M Justin Parisi wrote: > But referrals only help with initial mount; after the mount is established, > the connections stay where they were established. If a volume moves to a new > node, that doesn't keep locality. They're also not much help with FlexGroup > volumes. >

1 0

Re:
by Parisi, Justin 17 Aug '21

17 Aug '21

Nconnect can help with some performance issues, provided the performance issues are related to things that nconnect can help with - such as slot table exhaustion or a single TCP connection that has maxed out what it can do bandwidth wise. NFSv4.1 performance is nearly identical to v3 in ONTAP for sequential reads/writes. The performance issues mostly come from high metadata workloads. If you do want to use v4.1, move to ONTAP 9.9.1 and the latest Linux kernels you can. ________________________________ From: Toasters <toasters-bounces(a)teaparty.net> on behalf of Michael Bergman via Toasters <toasters(a)teaparty.net> Sent: Tuesday, August 17, 2021 7:57 AM To: Toasters Subject: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. _______________________________________________ Toasters mailing list Toasters(a)teaparty.net https://www.teaparty.net/mailman/listinfo/toasters

1 0

Re: pNFS
by Sebastian Goetze 17 Aug '21

17 Aug '21

Hi Justin, I'm wondering: Does that also go for *referrals*? Would the IP returned to the client respect the incoming LIF's Broadcast Domain and return the IP of a LIF in the same BD? Or should you refrain from referrals in that situation, too? I checked TR-4067, but didn't find a mention about that. @Florian: Could be, that NFS4.0/4.1 referrals are the solution to keeping your paths local, especially, if your volumes do not move around... Sebastian On 16.08.2021 18:41, Parisi, Justin via Toasters wrote: FYI TR-4067 calls out this exact issue as well. There’s currently no way to “blacklist” inelegible interfaces for pnfs. If it’s in the SVM, it will be used with pNFS, regardless of if it’s reachable. We have an open RFE to allow you to specify LIFs for pNFS to avoid this problem. In the meantime you can blacklist devices from the client as per page 54 of the tr. > _______________________________________________ > Toasters mailing list > Toasters(a)teaparty.net > https://www.teaparty.net/mailman/listinfo/toasters

2 1

Re: pNFS not working on vserver when several lifs with different Vlans available
by Florian Schmid 17 Aug '21

17 Aug '21

Hello Michael, may I ask which version of NFS are you using in your environment and what problems have you had with NFSv4.1? Especially the performance ones. Best regards Florian

1 0

Re:
by Tim McCarthy 17 Aug '21

17 Aug '21

Ain’t that the truth! I had a customer using 18 month old red hat kernels (not patch for a long time) They upgraded ontap to something modern and either did not realize (likely) or forgot they were using nfs v4.1/pnfs. As soon as ontap finished the boot of the last node to the latest version, ALL the rhel boxes panicked. Upon review it was due to a bug fixed 15 months ago in the kernel. The fix was simple, Chang the mounts to v3. So sane thought, if you go down the 4.1 path it is best to keep everything current both client and server to avoid nasty bugs Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Toasters <toasters-bounces(a)teaparty.net> on behalf of Michael Bergman via Toasters <toasters(a)teaparty.net> Sent: Tuesday, August 17, 2021 7:52:28 AM To: Toasters <toasters(a)teaparty.net> Subject: _______________________________________________ Toasters mailing list Toasters(a)teaparty.net https://www.teaparty.net/mailman/listinfo/toasters

1 0

Re: pNFS
by Michael Bergman 17 Aug '21

17 Aug '21

On 2021-08-17 12:44, Sebastian Goetze wrote: > @Florian: Could be, that NFS4.0/4.1 referrals are the solution to keeping > your paths local, especially, if your volumes do not move around... I concur, could be. We almost don't use NFSv4.1 at all (yet) for various reasons one main being performance issues due to the nature of our heavy NFS workloads W.r.t. performance in the NFS clients, if that's a worry, nconnect=x available in later kernels (e.g. in RHEL 8.x) can help speed things up. Quite a lot. It depends on the workload patterns you have. pNFS is interesting and can be good for certain applications and their workloads but it's cumbersome to work with and get to work smoothly. The clients running pNFS have been more the problem to get to behave well, in the past years at least. Nowadays w e.g. RHEL 8.x, possibly it's better. I would say it's still a VERY good idea that *all* your pNFS clients are exactly the same Linux kernel and version. I.e. the same distro and version of it. If you can't build such an environment, I'd recommend to refrain from using pNFS and try to mitigate any perceived or proven performance bottlenecks in other ways (e.g. nconnect=x can help, and a better different scale out config of a new ONTAP cluster, large FlexGroup(s) etc) /M

1 0

Re: pNFS not working on vserver when several lifs with different Vlans available
by Florian Schmid 17 Aug '21

17 Aug '21

Good morning, thank you very much for all those replys. I really haven't thought that :) Yes, our network wasn't designed for pNFS at all, because we have never used it. We have started now to use clients, which are using this by default and we have encountered this problem. Our storage network was ever only switched, so no routing is/was possible and we always had to choose the right IP range for the client and node. We also normally don't have huge clusters, so no volume movement either. But I have really thought, that the pNFS implementation is at least broadcast domain aware, but it seems it isn't. This means, that pNFS is not working in our environment. That's ok for us. Thanks a lot for the deeper insight you all have given me. Best regards Florian Schmid

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
1352
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters