On Nov 19, 2013, at 6:59 PM, Sandon Van Ness <[email protected]> wrote:
> Probably all. See this post I made a while back about a resize failing. > Knowing what issues that JFS has with > 32 TiB I was fully prepared for the > resize failing so I had everything completely backed up and was going to > reformat after anyway (to defrag it): > > http://www.mail-archive.com/[email protected]/msg01806.html > > I would probably reformat. Thanks. I found the 32 TB error reports but not until after I broke it. I appreciate the confirmation that it’s not an error just at 32 TB exactly; that makes the decision easier: I anticipate an ongoing need to live-resize and it looks like JFS just isn’t going to do that. > If you were in Socal Area I would be willing to lend you a 24 TB box to > offload it but it looks like you are not socal so good luck man. I appreciate the offer. I think things will work out though — I’m finding that as the hassle of having a read-only filesystem accumulates the budget available for new drives also rises. — Would there be any interest in a patch to make the resize operation immediately fail when newSize > 32 TB, rather than failing after breaking the on-disk structures? I’m not well versed in the JFS codebase but it seems like a pretty straightforward change that would users people a lot of pain, so I’d be willing to take a look at it if it’s something that might actually get into the mainline code. Zach ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
