Tag Info

New answers tagged

0

I know that this is pretty old but we came across this problem ourselves. We found in the MSI logfile that the information it retrieved regarding the various install folders (favorites) were pointing to an non-existant network drive. Check the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders for issues.


1

This looks like the old Server 2008 issue they eventually fixed with release of the Dynamic Cache Service addon: http://www.microsoft.com/en-us/download/details.aspx?id=9258 In a nutshell reads and writes are cached to memory which eventually fills it and makes the server unresponsive. I couldn't find anything regarding server 2012 and this, but the ...


3

I'm not familiar enough with NFS to know what specific locking issues you may be referencing, but I generally hear that OpenAFS works better with whole-file locks, yes. However, OpenAFS does not work well with byte-range locks across different machines (that is, locking certain byte ranges in a file, as opposed to locking entire files). If you are only ...


2

Filesystem should be fine. You'll probably have some gaps in log files and it's possible that scripts/programs that aren't scrupulous about checking the success of writes may have lost data but that's all. You might want to check that logging (apache and syslog) is working correctly after you fixed the space problem - a service reload should be all that is ...


0

check the boot log => it has probably failed an auto fsck Re-run the checks, fix the errors, and then it should cleanly boot/mount the drives next reboot. try a live cd of your distrobution or something like http://www.sysresccd.org/ That should get you going.


1

Boot to just a command line by adding init=/bin/bash to the kernel arguments in the boot loader. Open a shell in a new VT by typing openvt -- /bin/bash Continue the original boot sequence by typing exec /sbin/init in the first bash shell. Once the boot sequence stall you can switch to the shell opened by openvt and start collecting information about the ...


1

Maybe you have set your fstab options to prevent execution on this filesystem? Have a look at /etc/fstab, maybe you've set the noexec option.


0

After some years in the trench, my answer is ZFS and SmartOS. Here's a paper on the benchmarks: https://www.joyent.com/public-cloud/benchmarks/postgresql


0

After some lenghty troubleshooting with our support vendor, we found the solution. There was a process running that was started before the mounting of the vxfs filesystems. This process was writing data to /opt/CSCObac/var/rdu which is a nested directory of the /opt/CSCObac/var/ mountpoint. After killing this process, the disk usage was back to the expected ...


2

Yes, XFS is basically on data=writeback modus operandi. EXT4 is the same, and so NTFS and BTRFS and any modern filesystem. However, the common "wrong cases" (eg: crash/power loss when truncating a file) are all worked around in the code, so in practice EXT4 and XFS are very stable. On the other side, many distributions used EXT3 without barriers, which in ...


1

Somehow I came across this feature, called File Screening Management (https://technet.microsoft.com/en-us/library/cc732074.aspx). As it claims, it can be used for: "Define file screening templates that can be applied to new volumes or folders and that can be used across an organization". So, partially you can apply a file naming pattern, like "bill-_--_-.*" ...


0

/proc is a Virtual filesystem which does not reside on a disk, but it resides on system memory (RAM). The files and directories in this filesystem are used by system to register processes they run and also the setting (tunables) of the operating systems get loaded from the disk to the /proc filesystem when teh system boots up, so that the system doesnt have ...


1

Well, your biggest problem is that you didn't mount the image via a loop before running mkfs, which you probably meant to do (e.g. losetup /dev/loop0 /tmp/loop.img followed by mkfs.ext4 /dev/loop0) But, as to the shrinkage and why the numbers change, the 1.2M is actual file use; the 10M is disk allocation. That's saying "you have granted loop.img 10M on ...


0

This appears to be a bug in version 0.1.39 of mhddfs on Ubuntu. A workaround is to downgrade to 0.1.38 from Precise.



Top 50 recent answers are included