search for: 950gb

...used for a btrfs md setup, different hard drive sizes, brands, and interfaces. The last time I rebalanced I was using about 800GB of space on the 4.6TB array, and I started before I went to sleep and it was done when I woke up. I''m in the middle of a rebalance right now, currently using 950GB, and it has been a full day and the rebalancing is not done yet. Is this an expected change? Is there any way to tell how much longer it will take? Do you need to know more info about the setup? Thanks, — Mark Rada marada@uwaterloo.ca -- To unsubscribe from this list: send the line "un...

...w, bring a new one up, right back in, try it again, it repeats. What's interesting to me is that I have all kinds of other 'lesser' systems running CentOS 4.4, and I have none of these issues with them. My ~1.1TB raid 10 drive is sliced up into 4 parts, with the big one being about 950GB. Near as I can figure, I haven't hit any limitations, but I'm stumped by something that I *think* is probably either relatively trivial, or just a straight out hardware incompatibility. One thought is that it could be related to the Gb ethernet devices (bge). Commands like 'ifconf...

...ata > browseable = yes > fruit:time machine = yes > vfs objects = catia fruit streams_xattr > fruit:aapl = yes > valid users = tmachine > read only = No > inherit acls = yes > > > Expected TimeMachine snapshot: 130GB > Samba share size: 950GB > > smbd.log: > [2018/03/21 11:15:13.589109, 0] > ../source3/locking/share_mode_lock.c:439(share_mode_data_destructor) > store returned NT_STATUS_UNSUCCESSFUL > [2018/03/21 11:15:13.589216, 0] ../source3/lib/util.c:815(smb_panic_s3) > PANIC (pid 933): could not store sha...

...encrypt passwords = yes [TimeMachineD] path = /data browseable = yes fruit:time machine = yes vfs objects = catia fruit streams_xattr fruit:aapl = yes valid users = tmachine read only = No inherit acls = yes Expected TimeMachine snapshot: 130GB Samba share size: 950GB smbd.log: [2018/03/21 11:15:13.589109, 0] ../source3/locking/share_mode_lock.c:439(share_mode_data_destructor) store returned NT_STATUS_UNSUCCESSFUL [2018/03/21 11:15:13.589216, 0] ../source3/lib/util.c:815(smb_panic_s3) PANIC (pid 933): could not store share mode entry: NT_STATUS_UNSUCCESSF...

I am [trying to] perform a test prior to moving my data to solaris and zfs. Things are going very poorly. Please suggest what I might do to understand what is going on, report a meaningful bug report, fix it, whatever! Both to learn what the compression could be, and to induce a heavy load to expose issues, I am running with compress=gzip-9. I have two machines, both identical 800MHz P3 with