Re: Available disk space per tablespace
От | Christoph Berg |
---|---|
Тема | Re: Available disk space per tablespace |
Дата | |
Msg-id | Z9RNywZyd364KcZL@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: Available disk space per tablespace (Quan Zongliang <quanzongliang@yeah.net>) |
Ответы |
Re: Available disk space per tablespace
|
Список | pgsql-hackers |
Re: Quan Zongliang > According to the statvfs documentation for macOS > f_frsize The size in bytes of the minimum unit of allocation on this > file system. > f_bsize The preferred length of I/O requests for files on this file > system. Thanks for catching that. f_frsize is the correct field to use. The statvfs(3) manpage on Linux has it as well, but it's less pronounced there so I missed it: struct statvfs { unsigned long f_bsize; /* Filesystem block size */ unsigned long f_frsize; /* Fragment size */ fsblkcnt_t f_blocks; /* Size of fs in f_frsize units */ fsblkcnt_t f_bfree; /* Number of free blocks */ fsblkcnt_t f_bavail; /* Number of free blocks for unprivileged users */ > In addition, many systems use 1000 as 1k to represent the storage size. > Shouldn't we consider this factor as well? That would be a different pg_size_pretty() function, unrelated to this patch. I'm still unconvinced if we should use statfs() instead of statvfs() on *BSD or if their manpage is just trolling us and statvfs is just fine. DESCRIPTION The statvfs() and fstatvfs() functions fill the structure pointed to by buf with garbage. This garbage will occasionally bear resemblance to file system statistics, but portable applications must not depend on this. Christoph
Вложения
В списке pgsql-hackers по дате отправления: