HAMMER question
Hello, I was taking a peek at http://en.wikipedia.org/wiki/OneFS_distributed_file_system and curious if HAMMER will ever have features like this. TIA
Hammer question about pruning
Hi all, Im thinking about deploying DragonFly as a storage server. Company I work for needs fine snapshot/versioning granularity and I think Hammer would be good for that. The situation is like this: they want daily snapshots, but they want to keep every modification of files/databases since the last snapshot for at least 3 days. Is this as easy as configuring the pruning in hammer cleanup to 3d? Should reblocking still be done daily or also every 3 days? Thanks, Petr
Re: Hammer question about pruning
:Hi all, : :Im thinking about deploying DragonFly as a storage server. Company I work :for needs fine snapshot/versioning granularity and I think Hammer would be :good for that. The situation is like this: they want daily snapshots, but :they want to keep every modification of files/databases since the last :snapshot for at least 3 days. Is this as easy as configuring the pruning :in hammer cleanup to 3d? Should reblocking still be done daily or also :every 3 days? : :Thanks, : :Petr The pruning system currently throws away fine-grained history beyond the first snapshot. BUT, I actually reserved a field in the PFS structure to set the minimum fine-grained history retention. I just haven't added any code to use the field. I think what you are requesting is desireable, and it will not take much time for me to code it up. I will implement the feature today. As with other hammer features, the idea is to be able to run a prune, rebalance, or reblocking operation at any time. The timing of when you run these operations is not supposed to effect the retention policy. That will still be the case. -Matt Matthew Dillon dil...@backplane.com
Re: Hammer question about pruning
Thanks Matt, So if I set the prune-min to 3 days, and use even the default PFS config (1 day snapshot, 1 day prune, 1 day reblock) it will just work? Excellent! Petr
Re: Hammer question about pruning
:In regards to existing hammer instalations that run the initial HAMMER :release, do I have to upgrade to HAMMER WIP? : :Petr It isn't necessary for the pruning feature. If it is still calling it WIP then you have either an old kernel or an old hammer binary. Do not upgrade to the WIP version, it will break the filesystem (that's why there are so many warnings if you try to do it). With a recent kernel version 2 will be marked as 'NORM'. It is a different implementation then what was in WIP. If version is is marked as normal then it is safe to upgrade to it and the utility won't spew dire warnings at you when you do. But note that older kernels will not be able to read that filesystem. The upgrade will apply only to newly created directories. -Matt
Re: Hammer question about pruning
Sorry for the confusion, IM running a recent kernel + userland, but the file system was created about 9 months ago, this is what I have: min=1 wip=3 max=2 current=1 description=2.0 - First HAMMER release available versions: 1 NORM2.0 - First HAMMER release 2 NORM2.3 - New directory entry layout Should I switch to version 2 anyhow? Petr
Re: Hammer question about pruning
: :Sorry for the confusion, IM running a recent kernel + userland, but the file :system was created about 9 months ago, this is what I have: : :min=1 wip=3 max=2 current=1 description=2.0 - First HAMMER release :available versions: :1 NORM2.0 - First HAMMER release :2 NORM2.3 - New directory entry layout : :Should I switch to version 2 anyhow? : :Petr Yah, you can switch to v2. It will improve the directory layout for new directory topologies created after the upgrade. Though it still takes a reblocking pass or two to get it there (which will happen automatically by the hammer cleanup crons over the course of time). -Matt Matthew Dillon dil...@backplane.com
Hammer question
I am very intrigued with the HAMMER filesystem. I am a heavy Linux user and at work we use Linux exclusively. I was curious how hammer manages dynamic inodes. On ext3 we pre create inodes which is a fixed amount. How is hammer doing this? Sorry if this is a newbie question. I asked the same question on ext3 list and no response there. TIA
Re: Hammer question
:I am very intrigued with the HAMMER filesystem. I am a heavy Linux :user and at work we use Linux exclusively. I was curious how hammer :manages dynamic inodes. On ext3 we pre create inodes which is a fixed :amount. How is hammer doing this? : :Sorry if this is a newbie question. I asked the same question on ext3 :list and no response there. : :TIA Inodes in HAMMER are entries in the B-Tree. They are created and destroyed dynamically. Inode numbers are 64 bit quantities (well, actually 2^63 bits... the positive 64 bit integer space only). Inode numbers in HAMMER cannot be reused for the life of the filesystem. This allows HAMMER to track mirroring (and ultimately cluster) operations regardless of how long mirroring targets are offline. -Matt Matthew Dillon dil...@backplane.com
Re: Hammer question
Thankyou. I will start dust of my CS books to start looking into Btrees. On Tue, Feb 24, 2009 at 9:58 PM, Matthew Dillon dil...@apollo.backplane.com wrote: :I am very intrigued with the HAMMER filesystem. I am a heavy Linux :user and at work we use Linux exclusively. I was curious how hammer :manages dynamic inodes. On ext3 we pre create inodes which is a fixed :amount. How is hammer doing this? : :Sorry if this is a newbie question. I asked the same question on ext3 :list and no response there. : :TIA Inodes in HAMMER are entries in the B-Tree. They are created and destroyed dynamically. Inode numbers are 64 bit quantities (well, actually 2^63 bits... the positive 64 bit integer space only). Inode numbers in HAMMER cannot be reused for the life of the filesystem. This allows HAMMER to track mirroring (and ultimately cluster) operations regardless of how long mirroring targets are offline. -Matt Matthew Dillon dil...@backplane.com
