Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named file.dat for this example) that all
appear as ~1.5GB when using 'ls -l', but that (correctly) appear as ~250KB
files when using 'ls -s' or du commands:
edmudama$ ls -l file.dat
On Mon, 2 May 2011, Eric D. Mudama wrote:
Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named file.dat for this example) that all
appear as ~1.5GB when using 'ls -l', but that (correctly) appear as ~250KB
files when using 'ls -s' or du
Hi. While doing a scan of disk usage, I noticed the following
oddity.
I have a directory of files (named file.dat for this example) that
all
appear as ~1.5GB when using 'ls -l', but that (correctly) appear as
~250KB
files when using 'ls -s' or du commands:
These are probably just
On Mon, May 2 at 14:01, Bob Friesenhahn wrote:
On Mon, 2 May 2011, Eric D. Mudama wrote:
Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named file.dat for this example) that all
appear as ~1.5GB when using 'ls -l', but that (correctly)
On 05/ 2/11 08:41 PM, Eric D. Mudama wrote:
On Mon, May 2 at 14:01, Bob Friesenhahn wrote:
On Mon, 2 May 2011, Eric D. Mudama wrote:
Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named file.dat for this example) that all
appear as ~1.5GB
On Mon, May 2 at 14:01, Bob Friesenhahn wrote:
On Mon, 2 May 2011, Eric D. Mudama wrote:
Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named file.dat for this example) that all
appear as ~1.5GB when using 'ls -l', but that (correctly)
Also, sparseness need not be apparent to applications. Until recent
improvements to lseek(2) to expose hole/non-hole offsets, the only way
to know about sparseness was to notice that a file's reported size is
more than the file's reported filesystem blocks times the block size.
Sparse files in
On Mon, 2 May 2011, Eric D. Mudama wrote:
These are probably just sparse files. Nothing to be alarmed about.
They were created via CIFS. I thought sparse files were an iSCSI concept,
no?
Sparse files are a traditional Unix filesystem feature. Many/most
database files are sparse. All
On 05/02/11 14:02, Nico Williams wrote:
Also, sparseness need not be apparent to applications. Until recent
improvements to lseek(2) to expose hole/non-hole offsets, the only way
to know about sparseness was to notice that a file's reported size is
more than the file's reported filesystem
On Mon, May 2 at 20:50, Darren J Moffat wrote:
On 05/ 2/11 08:41 PM, Eric D. Mudama wrote:
On Mon, May 2 at 14:01, Bob Friesenhahn wrote:
On Mon, 2 May 2011, Eric D. Mudama wrote:
Hi. While doing a scan of disk usage, I noticed the following oddity.
I have a directory of files (named
On Mon, May 2, 2011 at 3:56 PM, Eric D. Mudama
edmud...@bounceswoosh.org wrote:
Yea, kept googling and it makes sense. I guess I am simply surprised
that the application would have done the seek+write combination, since
on NTFS (which doesn't support sparse) these would have been real
1.5GB
On Mon, 2 May 2011, Eric D. Mudama wrote:
Yea, kept googling and it makes sense. I guess I am simply surprised
that the application would have done the seek+write combination, since
on NTFS (which doesn't support sparse) these would have been real
1.5GB files, and there would be hundreds or
Then again, Windows apps may be doing seek+write to pre-allocate storage.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Mon, May 2, 2011 at 1:56 PM, Eric D. Mudama
edmud...@bounceswoosh.org wrote:
that the application would have done the seek+write combination, since
on NTFS (which doesn't support sparse) these would have been real
1.5GB files, and there would be hundreds or thousands of them in
normal
On Mon, May 2 at 15:30, Brandon High wrote:
On Mon, May 2, 2011 at 1:56 PM, Eric D. Mudama
edmud...@bounceswoosh.org wrote:
that the application would have done the seek+write combination, since
on NTFS (which doesn't support sparse) these would have been real
1.5GB files, and there would be
15 matches
Mail list logo
